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