git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Change in .gitignore handling: intended or bug?

From
Kevin Daudt <me@ikke.info>
Date
Mar 4, 2016, 11:56 UTC
Message-ID
<20160304115634.GC26609@ikke.info>
In-Reply-To
<1457071957.2027843.539286050.10CF8D0A@webmail.messagingengine.com>
On Fri, Mar 04, 2016 at 01:12:37AM -0500, Charles Strahan wrote:
Show 148 quoted lines
> I'm on 2.7.0.
> 
> Here's a quick sanity check:
> 
> ├── baz
> │   ├── quux
> │   │   ├── corge
> │   │   │   └── wibble.txt
> │   │   └── grault.txt
> │   └── waldo.txt
> └── foo
>     ├── bar.txt
>     └── garply.txt
> 
> $ git --version
> git version 2.7.0
> 
> $ git status -sb -uall
> ## Initial commit on master
> ?? baz/quux/corge/wibble.txt
> ?? baz/quux/grault.txt
> ?? baz/waldo.txt
> ?? foo/bar.txt
> ?? foo/garply.txt
> 
> 
> For the lazy (such as myself), this will set up an identical tree:
> 
> mkdir -p foo
> mkdir -p baz/quux/corge
> touch foo/bar.txt
> touch foo/garply.txt
> touch baz/waldo.txt
> touch baz/quux/grault.txt
> touch baz/quux/corge/wibble.txt
> cat <<"EOF" > .gitignore
> *
> !/foo
> !/foo/bar.txt
> !/baz
> !/baz/quux
> !/baz/quux/**/*
> EOF
> 
> 
> I just checked https://git-scm.com/docs/gitignore and the example at the
> bottom
> suggests that this behavior may be expected:
> 
>     $ cat .gitignore
>     # exclude everything except directory foo/bar
>     /*
>     !/foo
>     /foo/*
>     !/foo/bar
> 
> Note the /foo/*, explicitly ignoring the entries below /foo.
> 
> This wasn't always the case, though, so I'd love to hear if it was
> intentional
> (or if I've lost my mind, which is quite possible).
> 
> -Charles
> 
> 
> 
> On Fri, Mar 4, 2016, at 12:51 AM, Kevin Daudt wrote:
> > On Thu, Mar 03, 2016 at 09:11:56PM -0500, Charles Strahan wrote:
> > > Hello,
> > > 
> > > I've found a change in the way .gitignore works, and I'm not sure if
> > > it's a bug
> > > or intended.
> > > 
> > > Previously, one could use the following .gitignore:
> > > 
> > >     *
> > >     !/foo
> > >     !/foo/bar.txt
> > >     !/baz
> > >     !/baz/quux
> > >     !/baz/quux/**/*
> > > 
> > > And these files would be seen by git:
> > > 
> > >     foo/bar.txt
> > >     baz/quux/grault.txt
> > >     baz/quux/corge/wibble.txt
> > > 
> > > And these files would be ignored:
> > > 
> > >     foo/garply.txt
> > >     baz/waldo.txt
> > > 
> > > At some point (between git 2.6.0 and 2.7.0, I think), the behavior
> > > changed such
> > > that _none_ of the files above would be ignored. Previously, git would
> > > treat
> > > !/foo as an indication that it should not prune /foo, but that
> > > _wouldn't_ be
> > > sufficient to un-ignore the contents thereof. Now, it seems the new
> > > scheme
> > > treats !/foo as functionally equivalent to !/foo followed by !/foo/**/*
> > > in the
> > > old scheme.
> > > 
> > > I manage my home directory by making it a git repo, and using
> > > ~/.gitignore to
> > > selectively permit certain files or subdirectories to be seen by git.
> > > The recent
> > > change in behavior has resulted in sensitive directories like ~/.gpg
> > > being
> > > un-ignored. For reference, I've appended my .gitignore to the end of
> > > this email.
> > > 
> > > So, is this behavior intended, or is this a bug? If the former, is there
> > > an
> > > announcement explaining this change?
> > > 
> > > -Charles
> > > 
> > > [snip]
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe git" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > Works as intended for me:
> > 
> > ├── baz
> > │   ├── quux
> > │   │   ├── corge
> > │   │   │   └── wibble.txt
> > │   │   └── grault.txt
> > │   └── waldo.txt
> > └── foo
> >     ├── bar.txt
> >     └── garply.txt
> > 
> > $ git status -s -uall
> > ?? baz/quux/corge/wibble.txt
> > ?? baz/quux/grault.txt
> > ?? foo/bar.txt
> > 
> > garply.txt and waldo.txt are ignore, but the rest is still tracked.
> > 
> > I'm on 2.7.2.
> --
Verified that it's different in 2.7.0, but 2.7.2 gives expected output.
Previous: Charles StrahanNext: Duy Nguyen
Message 5 of 28 in “Change in .gitignore handling: intended or bug?”
  1. Charles StrahanMar 4, 2016
  2. Duy NguyenMar 4, 2016
  3. Kevin DaudtMar 4, 2016
  4. Charles StrahanMar 4, 2016
  5. Kevin DaudtMar 4, 2016
  6. Duy NguyenMar 4, 2016
  7. Junio C HamanoMar 4, 2016
  8. Junio C HamanoMar 4, 2016
  9. Duy NguyenMar 5, 2016
  10. Duy NguyenMar 5, 2016
  11. Charles StrahanMar 5, 2016
  12. Junio C HamanoMar 5, 2016
  13. Junio C HamanoMar 7, 2016
  14. Junio C HamanoMar 8, 2016
  15. Duy NguyenMar 8, 2016
  16. Junio C HamanoMar 8, 2016
  17. Duy NguyenMar 9, 2016
  18. Junio C HamanoMar 9, 2016
  19. Junio C HamanoMar 9, 2016
  20. dir.c: fix dir re-inclusion rules with "NODIR" and "MUSTBEDIR"Nguyễn Thái Ngọc Duy, Mar 9, 2016
  21. Junio C HamanoMar 9, 2016
  22. Duy NguyenMar 10, 2016
  23. Duy NguyenMar 9, 2016
  24. Junio C HamanoMar 9, 2016
  25. Duy NguyenMar 10, 2016
  26. Junio C HamanoMar 10, 2016
  27. Junio C HamanoMar 10, 2016
  28. Duy NguyenMar 10, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.