Re: Why does git track directory listed in .gitignore/".git/info/exclude"?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 30, 2008, 21:06 UTC
- Message-ID
- <7vfxwfgh0o.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <7vprvjgi9v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 31 quoted lines
> Adam Piatyszek <ediap@users.sourceforge.net> writes: >... >> Can you seen any drawbacks of such modification? > > I do not see a problem if you are saying: > > when the user has an entry 'dir/' in .gitignore, it > should match directory 'dir'. > > However, there is a subtle problem in a naive implementation of > that. IOW, > > when the user has an entry 'dir/' in .gitignore, behave > as if the entry were 'dir' instead. > > is wrong. > > When you say "foo", you mean "I want either 'foo' that is a > non-directory, or everything under 'foo' if that is a > directory". When you say "foo/", you are saying "I do not want > 'foo' if it is a non-directory. I want everything under 'foo' > if and only if that is a directory". Compare: > > git ls-files -s Makefile/ > git ls-files -s Makefile > > The first one is silent, and the latter answers. On the other > hand, for a directory, both of these give you the same: > > git ls-files Documentation/ > git ls-files Documentation
Perhaps "wrong" might have been too strong a word, and I should have said "inconsistent with other parts of the system."
It could be that people may find pathspec "Makefile/" meant exactly the same thing as "Makefile" in ls-files and other commands. If that is the case, then we could uniformly strip the trailing slash, both in all of these commands _and_ .gitignore entries.
In any case, their behaviour should be consistent.