Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths

> Eric Wong <normalperson@yhbt.net> writes:
> 
> > 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".