Alex Riesen <raa.lkml@xxxxxxxxx> writes:
> Noticed by a collegue of mine. Consider:
>
> $ cd $GIT/t
> $ git show 570f32266:t/test-lib.sh # works
> $ git show 570f32266:test-lib.sh # does not work
> $ git show 570f32266:./test-lib.sh # does not work
> $ git show 570f32266:/t/test-lib.sh # does not work
>
> Considering that the relative path names work as filters (and many
> agreed on that being useful), it would be nice to allow relative
> pathnames in blob specifications for git-show and git-cat-file.
>
> (besides the colon is a good delimiter, even tab-completion works with it)
If you think about it a bit, relative path names nor absolute
path names does and should not work. 570f32266:t/test-lib.sh
means path t/test-lib.sh staring from 570f32266^{tree}. Where
you are in the filesystem is not important and matters not for
this syntax. Besides if you access other branch file might be
not in filesystem (deleted file, or disjoint branch with separate
contents like 'todo' or 'html' branch in git.git repository).
Besides,
$ git show 570f32266:t/test-lib.sh # works
$ git show cc5ac8b72:test-lib.sh # also works
works... but 49d8bcd7a2df5 here is SHA-1 id of a 't/' tree
(shortened output of "git rev-parse 570f32266:t").
And I think that with bash-completion from contrib you complete
correct pathnames; don't rely on filesystem pathnames completion.
--
Jakub Narebski
Poland
ShadeHawk on #git
-
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
