Re: [PATCH] Teach ignore machinery about pattern "/"

From: Junio C Hamano <gitster@pobox.com>
Date: May 25, 2012, 17:32 UTC
Message-ID: <7vlikgtbcx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1337950056-26491-1-git-send-email-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

Show 5 quoted lines

> Pattern "/" is ambiguous because the slash can mean "anchor the
> pattern to this location" (e.g. /path), but it can also mean
> "match directories only" (e.g. path/). Currently git interprets it as
> the latter except that 'path' is an empty string, which makes this
> pattern totally useless.

Did the old version interprete it as the former? How does the above observation relate to the end-user help request in the other thread?

When talking about an ambiguous expression X that can be in multiple ways and each interpretation gives surprisingly different result, if there are ways A, B and C to unambiguously spell each and every of its possible and useful interpretations, and if one of the interpretations C is to ignore the expression altogether, it is preferrable to either

 (1) warn if it does not trigger anything useful to write a no-op; or
 (2) just ignore it if a no-op is a meaningful behaviour

when you see X.

> On the other hand, it's intuitive to read '/' as "match root
> directory", or equivalent to "/*". (The other way to see it is "match
> all directories", which leads to the same result).

I am a bit confused about the above, especially "The other way" part.

Does this alternative interpretation view "/" as "/foo" whose "foo" happens to be an empty string, or does it view "/" as "foo/" whose "foo" happens to be an empty string?

The former would mean "ignore foo, and don't bother descending into foo if it is a directory, as everything in it is ignored", while the latter would mean "anywhere in this directory and its subdirectories, if we see foo that is a directory, don't bother descending into it as everything in it is ignored."

What I am trying to get at is why you are making '/' the same as '/*' as opposed to '*/', '/*/', or even a plain '*'.

Show 8 quoted lines

> One may wonder why bother an "ignore all" pattern. The pattern is
> useful when you want to keep just a small portion of the working
> directory. But that's still a rare case.
>
> A more popular case would be sparse checkout, where ignore rules are
> used to _include_. The thus now "include all" pattern is used to say
> "make a sparse checkout that includes everything except this and
> this".

If the "sparse checkout" hack writes "/" for whatever reason, it should be corrected to write "*" (or perhaps "/*") instead. I do not see it as a valid factor to affect when we decide what should be done for a possibly ambiguous "/" entry in the exclude machinery.

> Recognize this special pattern and turn it the working equivalence
> pattern "/*"

Regardless of the answer to the "is it *, /*, */ or /*/" question above, I do not think silent conversion is a right solution for the ambiguity.