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:
> >> Eric Wong <normalperson@yhbt.net> writes:
> >> 
> >> > To find the blob object name given a tree and pathname, we were
> >> > incorrectly calling "git ls-tree" with a "--" argument followed
> >> > by the pathname of the file we wanted to get.
> >> >
> >> >   git ls-tree <TREE> -- --dashed/path/name.c
> >> >
> >> > Unlike many command-line interfaces, the "--" alone does not
> >> > symbolize the end of non-option arguments on the command-line.
> >> >
> >> > ls-tree interprets the "--" as a prefix to match against, thus
> >> > the entire contents of the --dashed/* hierarchy would be
> >> > returned because the "--" matches "--dashed" and every path
> >> > under it.
> >> 
> >> The above makes only half a sense to me.  In an empty directory:
> >
> > Ah, I think you missed this line:
> >
> > "the entire contents of the --dashed/* hierarchy would be"
> 
> Actually, that was what I was trying to demonstrate to be false.  Notice
> the empty output from the first ls-tree with only -- and no other pathspec
> on the command line.  "--" should not match "--dashed/*" anything (but
> also notice that I said "should" here).
> 
> >>     $ git init
> >>     Initialized empty Git repository in /tmp/empty/.git
> >>     $ mkdir -p ./--dashed/path
> >>     $ >./--dashed/path/name
> >
> > # Add a second file
> > 	>./--dashed/path/ame
> 
> 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.