Eric Wong <normalperson@xxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> I think that is an independent bug. Not just "--" but it appears "--d" >> seems to hit it (and this is an ancient bug---even v1.0.0 seems to have >> it). > >> I suspect that ls-tree needs a fix, not about "--" but about the pathspec >> filtering. It appears that the part that decides if a subtree is worth >> traversing into uses the correct "is a pathspec pattern match leading path >> components?" semantics (i.e. "--dashed" matches but "--" doesn't), but >> after traversing into subtrees, the part that emits the output uses a >> broken semantics "does the path have any pathspec patter as its prefix?" >> It shouldn't check for "prefix", but for "leading path components", in >> other words, the match must happen at directory boundaries. >> >> And I do not think *this* bug is too late to fix. We should fix it. > > From the ls-tree documentation, I was under the impression that "--" > matching "--dashed" was intended: > > When paths are given, show them (note that this isn't really raw > pathnames, but rather a list of patterns to match). > > It doesn't make sense to me match like this, either; but I do think it > was intended and it will break things if people depend on the > existing behavior. Ok, but then the decision to descend into --dashed should be consistent with that policy, no? Right now, it appears that giving "--" alone says "Anything under --dashed can never match that pattern, so I wouldn't bother recursing into it". -- 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
