gitignore broken in git 1.7.0.1: slash checks leading dirs

gitignore broken in git 1.7.0.1: slash checks leading dirs

[Jiri Slaby]

Hi,

having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
to be ignored though the documentation says:
***
If the pattern does not contain a slash /, git treats it as a shell
glob pattern and checks for a match against the pathname without
leading directories.
***

$ touch test
$ touch include/linux/vga_asdads.h
$ git ls-files -o --exclude-from=test
include/linux/vga_asdads.h
test
$ echo linux >test
$ git ls-files -o --exclude-from=test
test

This does not happen with git 1.6.

thanks,
-- 
js

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Johannes Sixt]

Jiri Slaby schrieb:
> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
> to be ignored

That's the behavior that I would expect.

> though the documentation says:
> ***
> If the pattern does not contain a slash /, git treats it as a shell
> glob pattern and checks for a match against the pathname without
> leading directories.
> ***

and this citation confirms my expectation. Note that it says "pathname",
not "filename". 'include/linux' is a "pathname".

-- Hannes

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Jiri Slaby]

On 03/05/2010 10:05 AM, Johannes Sixt wrote:
> Jiri Slaby schrieb:
>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>> to be ignored
> 
> That's the behavior that I would expect.
> 
>> though the documentation says:
>> ***
>> If the pattern does not contain a slash /, git treats it as a shell
>> glob pattern and checks for a match against the pathname without
>> leading directories.
>> ***
> 
> and this citation confirms my expectation. Note that it says "pathname",
> not "filename". 'include/linux' is a "pathname".

What are 'leading directories' then?

-- 
js

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Johannes Sixt]

Jiri Slaby schrieb:
> On 03/05/2010 10:05 AM, Johannes Sixt wrote:
>> Jiri Slaby schrieb:
>>> ***
>>> If the pattern does not contain a slash /, git treats it as a shell
>>> glob pattern and checks for a match against the pathname without
>>> leading directories.
>>> ***
>> and this citation confirms my expectation. Note that it says "pathname",
>> not "filename". 'include/linux' is a "pathname".
> 
> What are 'leading directories' then?

'include/' is the leading directory of 'include/linux'.

The cited sentence says that the particular check considers only the last
path component of the pathname.

-- Hannes

[PATCH 1/1] gitignore: do not ignore include/linux/

[Jiri Slaby]

linux entry in .gitignore means that everything in include/linux/
gets ignored with git 1.7.

Prepend a slash to entries which are toplevel to avoid that

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Johannes Sixt <j.sixt@viscovery.net>
---
 .gitignore |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/.gitignore b/.gitignore
index efab0eb..fe6ebb9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,16 +34,16 @@ modules.builtin
 #
 # Top-level generic files
 #
-tags
-TAGS
-linux
-vmlinux
-vmlinuz
-System.map
-Module.markers
-Module.symvers
-!.gitignore
-!.mailmap
+/tags
+/TAGS
+/linux
+/vmlinux
+/vmlinuz
+/System.map
+/Module.markers
+/Module.symvers
+!/.gitignore
+!/.mailmap
 
 #
 # Generated include files
-- 
1.7.0.1

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Jiri Slaby]

On 03/05/2010 10:16 AM, Johannes Sixt wrote:
> The cited sentence says that the particular check considers only the last
> path component of the pathname.

Thinking about it, there is no way to specify a *filename* no matter
where it lies? I.e. patterns such as *.o matches also a/b/test.o/test.c?
Am I missing something?

-- 
js

Re: [PATCH 1/1] gitignore: do not ignore include/linux/

[Jakub Narebski]

Jiri Slaby <jslaby@suse.cz> writes:

> linux entry in .gitignore means that everything in include/linux/
> gets ignored with git 1.7.
> 
> Prepend a slash to entries which are toplevel to avoid that
> 
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: Johannes Sixt <j.sixt@viscovery.net>
> ---
>  .gitignore |   20 ++++++++++----------
>  1 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index efab0eb..fe6ebb9 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -34,16 +34,16 @@ modules.builtin
>  #
>  # Top-level generic files
>  #
> -tags
> -TAGS
> -linux
> -vmlinux
> -vmlinuz
> -System.map
> -Module.markers
> -Module.symvers
> -!.gitignore
> -!.mailmap
> +/tags
> +/TAGS
> +/linux
> +/vmlinux
> +/vmlinuz
> +/System.map
> +/Module.markers
> +/Module.symvers
> +!/.gitignore
> +!/.mailmap
>  
>  #
>  # Generated include files

Actually you want to *not ignore* .gitignore and .mailmap (and
.gitattributes which is missing here) anywhere, not only as top-level
file.  So .gitignore and .mailmap should not be prepended with slash.

   #
   # Top-level generic files
   #
  -tags
  -TAGS
  -linux
  -vmlinux
  -vmlinuz
  -System.map
  -Module.markers
  -Module.symvers
  +/tags
  +/TAGS
  +/linux
  +/vmlinux
  +/vmlinuz
  +/System.map
  +/Module.markers
  +/Module.symvers
   !.gitignore
   !.mailmap


-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Jonathan Nieder]

Johannes Sixt wrote:
> Jiri Slaby schrieb:

>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>> to be ignored
>
> That's the behavior that I would expect.
>
>> though the documentation says:
>> ***
>> If the pattern does not contain a slash /, git treats it as a shell
>> glob pattern and checks for a match against the pathname without
>> leading directories.
>> ***
>
> and this citation confirms my expectation. Note that it says "pathname",
> not "filename". 'include/linux' is a "pathname".

It would be more precise to say this citation does not have much to do
with it.  'include/linux' contains a slash, so that paragraph does not
describe what it means.

The next paragraph is more on point:

 · Otherwise, git treats the pattern as a shell glob suitable for
   consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the
   pattern will not match a / in the pathname. For example,
   "Documentation/*.html" matches "Documentation/git.html" but not
   "Documentation/ppc/ppc.html". A leading slash matches the beginning of
   the pathname; for example, "/*.c" matches "cat-file.c" but not
   "mozilla-sha1/sha1.c".

The relevant sentence is the last one, and I can see how the length of the
paragraph might be daunting.  Maybe splitting it up would help?

 · Otherwise, git treats the pattern as a shell glob suitable for
   consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the
   pattern will not match a / in the pathname. For example,
   "Documentation/*.html" matches "Documentation/git.html" and
   "tools/perf/Documentation/perf-diff.html" but not
   "Documentation/ppc/ppc.html".

 · A leading slash matches the beginning of the pathname; for example,
   "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".

Not sure.

Jonathan

-- %< --
Subject: gitignore.5: Clarify that path matches are not anchored

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 Documentation/gitignore.txt |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 98c459d..fa15422 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -89,10 +89,13 @@ Patterns have the following format:
    for consumption by fnmatch(3) with the FNM_PATHNAME flag:
    wildcards in the pattern will not match a / in the pathname.
    For example, "Documentation/\*.html" matches
-   "Documentation/git.html" but not
-   "Documentation/ppc/ppc.html".  A leading slash matches the
-   beginning of the pathname; for example, "/*.c" matches
-   "cat-file.c" but not "mozilla-sha1/sha1.c".
+   "Documentation/git.html" and
+   "tools/perf/Documentation/perf-diff.html" but not
+   "Documentation/ppc/ppc.html".
+
+ - A leading slash matches the beginning of the pathname;
+   for example, "/*.c" matches "cat-file.c" but not
+   "mozilla-sha1/sha1.c".
 
 An example:
 
-- 
1.7.0

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Jonathan Nieder]

Jonathan Nieder wrote:
> Johannes Sixt wrote:
>> Jiri Slaby schrieb:
>
>>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>>> to be ignored
[...]
>> and this citation confirms my expectation. Note that it says "pathname",
>> not "filename". 'include/linux' is a "pathname".
>
> It would be more precise to say this citation does not have much to do
> with it.  'include/linux' contains a slash, so that paragraph does not
> describe what it means.

Curse my quick reading.  Sorry for the nonsense, please ignore.

My suggested patch still might make sense, though. :)

Jonathan

Re: [PATCH 1/1] gitignore: do not ignore include/linux/

[Jiri Slaby]

On 03/05/2010 11:43 AM, Jakub Narebski wrote:
>> +!/.gitignore
>> +!/.mailmap
> 
> Actually you want to *not ignore* .gitignore and .mailmap (and
> .gitattributes which is missing here) anywhere, not only as top-level
> file.  So .gitignore and .mailmap should not be prepended with slash.

<and moved out of the 'Top-level generic files' section then>

-- 
js

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Johannes Sixt]

Jonathan Nieder schrieb:
>  · Otherwise, git treats the pattern as a shell glob suitable for
>    consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the
>    pattern will not match a / in the pathname. For example,
>    "Documentation/*.html" matches "Documentation/git.html" and
>    "tools/perf/Documentation/perf-diff.html" but not
>    "Documentation/ppc/ppc.html".

This is not correct: When the pattern "Documentation/*.html" matches
"Documentation/git.html", then it cannot match
"tools/perf/Documentation/perf-diff.html". This is because patterns that
contain a slash (after stripping a trailing slash) are anchored at the
directory that contains the .gitignore.

Said pattern would match the latter name only if it appeared in
tools/perf/.gitignore (but in this case it wouldn't match the former name,
of course).

-- Hannes

[PATCH] gitignore.5: Clarify matching rules

[Jonathan Nieder]

Patterns containing a / are implicitly anchored to the directory
containing the relevant .gitignore file.

Patterns not containing a / are textual matches against the path
name relative to the directory containing .gitignore.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Johannes Sixt wrote:

> When the pattern "Documentation/*.html" matches
> "Documentation/git.html", then it cannot match
> "tools/perf/Documentation/perf-diff.html". This is because patterns that
> contain a slash (after stripping a trailing slash) are anchored at the
> directory that contains the .gitignore.

Oh!  The documentation could definitely use clarification here.

Thanks.

 Documentation/gitignore.txt |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 98c459d..e10fa88 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -83,16 +83,20 @@ Patterns have the following format:
 
  - If the pattern does not contain a slash '/', git treats it as
    a shell glob pattern and checks for a match against the
-   pathname without leading directories.
+   pathname relative to the location of the `.gitignore` file
+   (relative to the toplevel of the work tree if not from a
+   `.gitignore` file).
 
  - Otherwise, git treats the pattern as a shell glob suitable
    for consumption by fnmatch(3) with the FNM_PATHNAME flag:
    wildcards in the pattern will not match a / in the pathname.
    For example, "Documentation/\*.html" matches
-   "Documentation/git.html" but not
-   "Documentation/ppc/ppc.html".  A leading slash matches the
-   beginning of the pathname; for example, "/*.c" matches
-   "cat-file.c" but not "mozilla-sha1/sha1.c".
+   "Documentation/git.html" but not "Documentation/ppc/ppc.html"
+   or "tools/perf/Documentation/perf.html".
+
+ - A leading slash matches the beginning of the pathname.
+   For example, "/*.c" matches "cat-file.c" but not
+   "mozilla-sha1/sha1.c".
 
 An example:
 
-- 
1.7.0

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Jiri Slaby schrieb:
>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>> to be ignored
>
> That's the behavior that I would expect.

Also the initial report made it sound as if there were a regression, but
it doesn't seem to be the case; I don't see it behaving any differently
among 1.7.0, 1.7.0.1, 1.6.0, 1.6.6, or even 1.5.4.

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Jonathan Nieder]

Jiri Slaby wrote:

> Thinking about it, there is no way to specify a *filename* no matter
> where it lies? I.e. patterns such as *.o matches also a/b/test.o/test.c?
> Am I missing something?

Is

 *.o
 !*.o/

what you are looking for?  The first line matches *.o anywhere, and
the second matches *.o anywhere as long as it is a directory.

Re: gitignore broken in git 1.7.0.1: slash checks leading dirs

[Jiri Slaby]

On 03/05/2010 06:25 PM, Jonathan Nieder wrote:
> Jiri Slaby wrote:
> 
>> Thinking about it, there is no way to specify a *filename* no matter
>> where it lies? I.e. patterns such as *.o matches also a/b/test.o/test.c?
>> Am I missing something?
> 
> Is
> 
>  *.o
>  !*.o/
> 
> what you are looking for?  The first line matches *.o anywhere, and
> the second matches *.o anywhere as long as it is a directory.

As I wrote above, *.o also matches against a/b/test.o/test.c, correct?

Re: [PATCH 1/1] gitignore: do not ignore include/linux/

[Américo Wang]

On Fri, Mar 5, 2010 at 5:20 PM, Jiri Slaby <jslaby@suse.cz> wrote:
> linux entry in .gitignore means that everything in include/linux/
> gets ignored with git 1.7.
>
> Prepend a slash to entries which are toplevel to avoid that

New change in git 1.7?

Re: [PATCH 1/1] gitignore: do not ignore include/linux/

[David Rientjes]

On Fri, 5 Mar 2010, Jiri Slaby wrote:

> On 03/05/2010 11:43 AM, Jakub Narebski wrote:
> >> +!/.gitignore
> >> +!/.mailmap
> > 
> > Actually you want to *not ignore* .gitignore and .mailmap (and
> > .gitattributes which is missing here) anywhere, not only as top-level
> > file.  So .gitignore and .mailmap should not be prepended with slash.
> 
> <and moved out of the 'Top-level generic files' section then>
> 

Please either revert 3b2a8c8f3c65 or merge the fixed up patch for 
2.6.34-rc2, otherwise include/linux will continue to be ignored by git 
just like it is for 2.6.34-rc1.

Re: [PATCH 1/1] gitignore: do not ignore include/linux/

[Américo Wang]

On Wed, Mar 10, 2010 at 6:07 PM, David Rientjes <rientjes@google.com> wrote:
> On Fri, 5 Mar 2010, Jiri Slaby wrote:
>
>> On 03/05/2010 11:43 AM, Jakub Narebski wrote:
>> >> +!/.gitignore
>> >> +!/.mailmap
>> >
>> > Actually you want to *not ignore* .gitignore and .mailmap (and
>> > .gitattributes which is missing here) anywhere, not only as top-level
>> > file.  So .gitignore and .mailmap should not be prepended with slash.
>>
>> <and moved out of the 'Top-level generic files' section then>
>>
>
> Please either revert 3b2a8c8f3c65 or merge the fixed up patch for
> 2.6.34-rc2, otherwise include/linux will continue to be ignored by git
> just like it is for 2.6.34-rc1.

Why not apply the patch from Jiri? Since this problem is introduced
by new version of git, not that commit.

Re: [PATCH 1/1] gitignore: do not ignore include/linux/

[David Rientjes]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 940 bytes --]

On Wed, 10 Mar 2010, Américo Wang wrote:

> >> >> +!/.gitignore
> >> >> +!/.mailmap
> >> >
> >> > Actually you want to *not ignore* .gitignore and .mailmap (and
> >> > .gitattributes which is missing here) anywhere, not only as top-level
> >> > file.  So .gitignore and .mailmap should not be prepended with slash.
> >>
> >> <and moved out of the 'Top-level generic files' section then>
> >>
> >
> > Please either revert 3b2a8c8f3c65 or merge the fixed up patch for
> > 2.6.34-rc2, otherwise include/linux will continue to be ignored by git
> > just like it is for 2.6.34-rc1.
> 
> Why not apply the patch from Jiri? Since this problem is introduced
> by new version of git, not that commit.
> 

Like I said, please either revert the commit that added "linux" to 
.gitignore or merge Jiri's patch.  I'm not interested in engaging in a 
discussion about what can or cannot be merged during rc cycles, I just 
hope this is resolved for rc2.