Re: [PATCH 2/2] tools/python: add .gitignore file

[Juergen Gross <jgross@xxxxxxxx>]

On 22.11.23 10:59, Jan Beulich wrote:
> On 22.11.2023 10:53, Juergen Gross wrote:
> > On 22.11.23 10:21, Jan Beulich wrote:
> > > On 22.11.2023 09:57, Juergen Gross wrote:
> > > > On 22.11.23 09:39, Jan Beulich wrote:
> > > > > On 22.11.2023 09:31, Juergen Gross wrote:
> > > > > > --- /dev/null
> > > > > > +++ b/tools/python/.gitignore
> > > > > > @@ -0,0 +1,4 @@
> > > > > > +build/*
> > > > > Are this and just build/ actually equivalent? Looking at our top-level
> > > > > .gitignore, I see e.g. extras/ and install/*, which I would expect want
> > > > > both treating the same? The form with a wildcard, to me at least,
> > > > > doesn't obviously include the directory itself ...
> > > > The .gitignore specification [1] suggests that we should use build/ (same for
> > > > the new entry), as otherwise entries in subdirectories would not match.
> > > The description there of what a trailing slash means isn't really clear.
> > "If there is a separator at the end of the pattern then the pattern will only
> > match directories, otherwise the pattern can match both files and directories."
> >
> > "The pattern foo/ will match a directory foo and paths underneath it, but will
> > not match a regular file or a symbolic link foo"
> But this is all about entries named "foo". Nothing is said about whether
> foo/ also includes foo/bar.c.
>
> > > Nothing is said about anything underneath the specified directory. Also
> > > nothing is said about what a trailing /* means towards the named directory.
> > "The pattern foo/*, matches foo/test.json (a regular file), foo/bar (a
> > directory), but it does not match foo/bar/hello.c (a regular file), as the
> > asterisk in the pattern does not match bar/hello.c which has a slash in it."
> Similarly here - nothing is said about foo itself. Yet from us successfully
> using foo/* entries I derive that they actually cover foo as well, no matter
> whether that's actually sensible.
This can all be tested rather easily with "git check-ignore" (assuming that git
itself is trusted to act correctly).

My tests were done with git version 2.35.3

This test suggests that "/build/*" won't match with "build", but with "build/x"
and "build/x/y".

"/build/" matches with "build", "build/x" and "build/x/y".

So using "/build/" seems to be the pattern to use.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature