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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 30, 2009, 06:44 UTC
Message-ID: <7v3acvldc7.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090329215651.GA4355@dcvr.yhbt.net>

Eric Wong <normalperson@yhbt.net> writes:

Show 22 quoted lines

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

Show 7 quoted lines

>>     $ 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).

> [1] But if we had time travel we could just release git before any other
> SCM and hopefully not have to deal with SVN at all :)

;-)

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.