Thread (17 messages) flat view 17 messages, 8 authors, 2016-08-11

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

From: Eric Wong <hidden>
Date: 2016-06-15 22:46:31

Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] wrote:
quoted
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"
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).
quoted
quoted
    $ 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.
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.

-- 
Eric Wong
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help