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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> 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 '*'.

> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google