Eric Wong <normalperson@xxxxxxxx> 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?
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.
"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.
builtin-ls-tree.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 22008df..08c4307 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -186,6 +186,12 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
if (get_sha1(argv[1], sha1))
die("Not a valid object name %s", argv[1]);
+ if (3 < argc && !strcmp(argv[2], "--")) {
+ /* ls-tree <tree> -- pathspec */
+ argc--;
+ argv++;
+ warning("ignoring -- in 'ls-tree <tree> -- <pathspec>'");
+ }
pathspec = get_pathspec(prefix, argv + 2);
tree = parse_tree_indirect(sha1);
if (!tree)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
