| Message ID | 20231122083153.24101-3-jgross@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | tools: add two local .gitignore files | expand |
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 ... > +xen.egg-info/* > +xen/lowlevel/xl/_pyxl_types.c > +xen/lowlevel/xl/_pyxl_types.h Since wildcards can be used here, how about just xen/lowlevel/xl/_pyxl_types.[ch] ? Jan
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. I'm not sure why "git status" doesn't show those files in deeper levels, but maybe I've misread the doc. > >> +xen.egg-info/* >> +xen/lowlevel/xl/_pyxl_types.c >> +xen/lowlevel/xl/_pyxl_types.h > > Since wildcards can be used here, how about just > > xen/lowlevel/xl/_pyxl_types.[ch] Fine with me. Juergen [1]: https://git-scm.com/docs/gitignore
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. Nothing is said about anything underneath the specified directory. Also nothing is said about what a trailing /* means towards the named directory. What _is_ said is that all the new entries here should start with a slash, to avoid matching similarly named subdirectories further into tools/python/. Unless I misunderstand the intention of this .gitignore entry and the goal is to match anywhere in the subtree. Jan
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" > 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." > What _is_ said is that all the new entries here should start with a slash, > to avoid matching similarly named subdirectories further into tools/python/. > Unless I misunderstand the intention of this .gitignore entry and the goal > is to match anywhere in the subtree. You are right, I should change that. Juergen
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. Jan
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. "... and paths underneath it" is rather clear IMHO. > >>> 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. I guess this is covered by "*" matching an empty string, too. I agree that this isn't spelled out explicitly anywhere, but it can be implied from: "The pattern hello.* matches any file or directory whose name begins with hello." I agree this should be mentioned explicitly to be the case. Juergen
On 22.11.2023 11:07, Juergen Gross wrote: > 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. > > "... and paths underneath it" is rather clear IMHO. Considering other text - no. To me is means other directories named foo/, e.g. bar/foo/. Jan
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
diff --git a/.gitignore b/.gitignore index 3009545af2..5b8f23271e 100644 --- a/.gitignore +++ b/.gitignore @@ -213,7 +213,6 @@ tools/misc/xencov tools/pkg-config/* tools/qemu-xen-build tools/xentrace/xenalyze -tools/python/build/* tools/tests/depriv/depriv-fd-checker tools/tests/x86_emulator/*.bin tools/tests/x86_emulator/*.tmp @@ -370,8 +369,6 @@ tools/ocaml/test/raise_exception tools/debugger/kdd/kdd tools/firmware/etherboot/ipxe.tar.gz tools/firmware/etherboot/ipxe/ -tools/python/xen/lowlevel/xl/_pyxl_types.c -tools/python/xen/lowlevel/xl/_pyxl_types.h tools/xl/xl docs/txt/misc/*.txt diff --git a/tools/python/.gitignore b/tools/python/.gitignore new file mode 100644 index 0000000000..ffee7b4c4b --- /dev/null +++ b/tools/python/.gitignore @@ -0,0 +1,4 @@ +build/* +xen.egg-info/* +xen/lowlevel/xl/_pyxl_types.c +xen/lowlevel/xl/_pyxl_types.h
Add a local .gitignore file for tools/python. As at least on some systems (e.g. OpenSUSE Leap 15.5) the build will produce a tools/python/xen.egg-info directory, add it to the new .gitignore file, too. Signed-off-by: Juergen Gross <jgross@suse.com> --- .gitignore | 3 --- tools/python/.gitignore | 4 ++++ 2 files changed, 4 insertions(+), 3 deletions(-) create mode 100644 tools/python/.gitignore