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

Junio C Hamano [off-list ref] wrote:

Eric Wong [off-list ref] writes:

quoted

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"

    $ git init
    Initialized empty Git repository in /tmp/empty/.git
    $ mkdir -p ./--dashed/path
    $ >./--dashed/path/name

# Add a second file
	>./--dashed/path/ame

    $ git add .
    $ git ls-files
    --dashed/path/name
    $ git commit -a -m initial
    [master (root-commit) cd44284] initial
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 --dashed/path/name
    $ git ls-tree HEAD^{tree} --
    $ git ls-tree HEAD^{tree} -- --dashed/path/name
    100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	--dashed/path/name
    $ mkdir ./--
    $ >./--/eman
    $ git add .
    $ git commit -m second
    [master 80f8ef9] second
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 --/eman
    $ git ls-tree HEAD^{tree} -- --dashed/path
    100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	--/eman
    040000 tree 23e59e0c91294c39ac7c5a2e39efb01d878de9a0	--dashed/path

This is similar to the problem I was experiencing.

    $ exit

Perhaps the problem repository had a pathname that is exactly -- (in
addition to --dashed/), and ls-tree emitted everything under --/
hierarchy?  In other words, your fix to git-svn may be correct and I am
reading your problem description above incorrectly?

I think so.

As the command always takes exactly one tree, it could be argued that it
is not a bug that it does not honour the usual -- convention, even though
I am tempted to think it is of a very dark shade of gray.  It is certainly
something that we would have done differently if we were implementing the
command today.

Well, if somebody had a path in their repo called "--full-name" then it
would certainly be ambiguous and respecting "--" would help.  Something
we should definitely go back and fix if we have time travel[1]

"Fixing" ls-tree would be trivial to ignore the first "--" if it precedes
other pathspecs (see below), but the command is a plumbing, and such a
change will break existing scripts that have relied on the existing
behaviour since 2005, so I do not think it is worth the risk of causing
such silent breakages to them.  Besides, with such a "fix", fixing of user
scripts will become much more cumbersome, as they need to detect the
version of git and drive ls-tree differently.

I concur completely.  I didn't propose a "fix" to ls-tree for exactly
the reasons you stated.


[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 :)

-- 
Eric Wong