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

[Junio C Hamano <gitster@pobox.com>]

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".