From: Adam Piatyszek <ediap@users.sourceforge.net>
Date: Thu, 31 Jan 2008 22:53:52 GMT
Subject: Re: [PATCH] gitignore(5): Allow "foo/" in ignore list to match directory "foo"
Message-ID: <47A25180.5000903@users.sourceforge.net>
In-Reply-To: <7vr6fxbr5a.fsf@gitster.siamese.dyndns.org>

* Junio C Hamano [31 I 2008 22:51]:
> [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  .:................................:.