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 http://vger.kernel.org/majordomo-info.html