Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 30, 2009, 18:05 UTC
- Message-ID
- <7vy6umdgxq.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <20090330174151.GA32728@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
Show 26 quoted lines
> Junio C Hamano <gitster@pobox.com> 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".