On Sat, May 26, 2012 at 12:32 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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? That calls for bit of testing, which I'll do soon. > How does the above > observation relate to the end-user help request in the other thread? I assume you meant the recent sparse-checkout thread. "/" happens to work due to (probably) a mistake in sparse-checkout v1.7.2 even though "/" behavior is undefined. This sets a specific behavior to "/" and makes 1.7.10 treat "/" like 1.7.2. > 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. except that we do the ignoring in (2) but I don't see this as a meaningful behavior. >> 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 latter. Though there may be two way of interpreting the empty string as pattern. The computer would happily say "match nothing", but my human brain tends to thinkg "match everything" as "match nothing" does not really makes sense as a pattern. > 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 '*'. Because I see "/" as a special case of "/foo". It makes more sense than "/" as a special case of "foo/", at least not without more thoughts on it. >> 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. That's one way of seeing it. What I propose in the patch is "this is useless no-op pattern (*), let's assign some meaning to it, what makes most sense" (*) still needs verification though. > >> 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. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html