git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Björn Steinbrink <b.steinbrink@gmx.de>
Date
Mar 30, 2009, 05:28 UTC
Message-ID
<20090330052817.GB2681@atjola.homenet>
In-Reply-To
<7v8wmoqdc1.fsf@gitster.siamese.dyndns.org>
On 2009.03.29 13:33:02 -0700, Junio C Hamano wrote:
Show 48 quoted lines
> 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:
> 
>     $ git init
>     Initialized empty Git repository in /tmp/empty/.git
>     $ mkdir -p ./--dashed/path
>     $ >./--dashed/path/name
>     $ 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
>     $ 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?

Your test case is flawed, because you only have a single path in --dashed/

Initialized empty Git repository in /home/doener/test/.git/
$ mkdir ./--dashed
$ touch ./--dashed/{1,2}
$ git add .
$ git ls-files
--dashed/1
--dashed/2
$ git commit -m init
[master (root-commit) ae7cd83] init
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 --dashed/1
 create mode 100644 --dashed/2
$ git ls-tree HEAD^{tree}
040000 tree f353b342b53872c6a510229524f819c4fe0d5c1b	--dashed
$ git ls-tree HEAD^{tree} --
$ git ls-tree HEAD^{tree} -- --dashed
040000 tree f353b342b53872c6a510229524f819c4fe0d5c1b	--dashed
$ git ls-tree HEAD^{tree} -- --dashed/
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	--dashed/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	--dashed/2
$ git ls-tree HEAD^{tree} -- --dashed/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	--dashed/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	--dashed/2
Or even more weird (at least to me):
Initialized empty Git repository in /home/doener/test/.git/
$ mkdir foo fab
$ touch {foo,fab}/{1,2}
$ git add .
$ git commit -m init
[master (root-commit) fdb7bb3] init
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 fab/1
 create mode 100644 fab/2
 create mode 100644 foo/1
 create mode 100644 foo/2
$ git ls-files foo/1 fab/1
fab/1
foo/1
$ git ls-files foo/1 fab/1 f
fab/1
foo/1
$ git ls-tree HEAD^{tree} foo/1 fab/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	fab/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	foo/1
$ git ls-tree HEAD^{tree} foo/1 fab/1 f
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	fab/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	fab/2
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	foo/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	foo/2

So if you go into some tree, any additional pattern that is a prefix of the tree name will match the tree and its contents.

Björn
Previous: Junio C HamanoNext: Anton Gyllenberg
Message 26 of 28 in “svn clone Checksum mismatch question”
  1. Gilbert LiddellMar 26, 2009
  2. Björn SteinbrinkMar 26, 2009
  3. Gilbert LiddellMar 26, 2009
  4. Sverre RabbelierMar 26, 2009
  5. Gilbert LiddellMar 26, 2009
  6. Johannes SchindelinMar 26, 2009
  7. Anton GyllenbergMar 26, 2009
  8. Anton GyllenbergMar 27, 2009
  9. Eric WongMar 29, 2009
  10. git-svn: fix ls-tree usage with dash-prefixed pathsEric Wong, Mar 29, 2009
  11. Junio C HamanoMar 29, 2009
  12. Eric WongMar 29, 2009
  13. Junio C HamanoMar 30, 2009
  14. Eric WongMar 30, 2009
  15. Junio C HamanoMar 30, 2009
  16. Eric WongMar 30, 2009
  17. Björn SteinbrinkMar 31, 2009
  18. Björn SteinbrinkMar 31, 2009
  19. Björn SteinbrinkMar 31, 2009
  20. tree_entry_interesting: Only recurse when the pathspec is a leading path componentBjörn Steinbrink, Mar 31, 2009
  21. Junio C HamanoApr 2, 2009
  22. match_tree_entry(): a pathspec only matches at directory boundariesJunio C Hamano, Apr 2, 2009
  23. Linus TorvaldsApr 2, 2009
  24. Björn SteinbrinkApr 2, 2009
  25. Junio C HamanoApr 3, 2009
  26. Björn SteinbrinkMar 30, 2009
  27. Anton GyllenbergMar 30, 2009
  28. Peter HarrisMar 26, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.