Re: [PATCH] gitignore(5): Allow "foo/" in ignore list to match directory "foo"

From: Adam Piatyszek <ediap@users.sourceforge.net>
Date: Jan 31, 2008, 22:53 UTC
Message-ID: <47A25180.5000903@users.sourceforge.net>
In-Reply-To: <7vr6fxbr5a.fsf@gitster.siamese.dyndns.org>

* Junio C Hamano [31 I 2008 22:51]:

Show 13 quoted lines

> [PATCH] gitignore(5): Allow "foo/" in ignore list to match directory "foo"
> 
> A pattern "foo/" in the exclude list did not match directory
> "foo", but a pattern "foo" did.  This just strips the trailing
> slash from such input.
> 
> This makes the behaviour slightly inconsistent with that of
> pathspecs, where "foo/" only matches directory "foo" and not
> regular file "foo" and make "foo/" in the ignore list match
> regular file "foo" happily.  This may hopefully does not matter
> in practice.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

This is more or less what I suggested originally. ;-)

Anyway, even if this new behaviour is not consistent with that of pathspecs, it is not worse than the current behaviour of git. I.e. now you have to use "foo" to ignore the "foo" directory and its contents, but it does not protect you from masking the file "foo" in the same repository.

However, it is not possible to have both the "foo" directory and "foo" file in the same directory level of a repository at the same time. So, the problem with this patch might be only when one replaces the ignored directory "foo" with a file using the same name and forgets to remove the "foo/" entry from .gitignore or .git/info/exclude. But exactly the same situation can occur for the current implementation.

So, I tend to agree that your latest patch is a sensible solution for 99.9% of cases.

BR, /Adam

-- 
.:.  Adam Piatyszek (ediap)  .:.....................................:.
.:.  ediap@users.sourceforge.net  .:................................:.