Re: log/show: relative pathnames do not work in rev:path
- From
Alex Riesen <raa.lkml@gmail.com>
- Date
- Dec 18, 2007, 20:46 UTC
- Message-ID
- <20071218204623.GC2875@steel.home>
- In-Reply-To
- <m3d4t3q4e5.fsf@roke.D-201>
Jakub Narebski, Tue, Dec 18, 2007 18:50:20 +0100:
Show 23 quoted lines
> Alex Riesen <raa.lkml@gmail.com> 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).Not convinced. It is *not* the plumbing problem I was trying to describe. They discussion, metaphorically, should not have left the command-line parser.
I think that we have parsing of the blob locators at the wrong level: so that git-show, git-log and git-diff can handle its pathnames as they handle path filters (relative to cwd), and git-cat-file, git-diff-tree, git-rev-list, etc can handle theirs always relative to the project root.
I actually do not see any problem for git-show (being porcelain-level program) to treat *each and every* path anywhere relatively to the current directory. It is just more comfortable.
Please consider the following patches.