Re: log/show: relative pathnames do not work in rev:path

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 18, 2007, 21:24 UTC
Message-ID: <200712182224.28152.jnareb@gmail.com>
In-Reply-To: <20071218204623.GC2875@steel.home>

On Tue, 18 Dec 2007, Alex Riesen wrote:

Show 33 quoted lines

> Jakub Narebski, Tue, Dec 18, 2007 18:50:20 +0100:
>> 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),

What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>. IMHO "<tree-ish>:<path>" should be considered (and is considered) as one object: current working directory doesn't matter at all there, contrary to "<tree-ish> -- <pathspec>" where it is natural that <pathspec> is relative to current working directory.

What should git do in your proposal when we are on master branch in Documentation subdirectory, and want to check TODO file in todo branch? "git show todo:TODO" is most natural IMHO.

Note that for true <tree> as <tree-ish> you just don't know where in the working area directory hierarchy <tree> can be. This means you do't know relation of <tree> and <path> in <tree>:<path> to cwd.

> and git-cat-file, 
> git-diff-tree, git-rev-list, etc can handle theirs always relative to
> the project root.

Not "relative to project root". Relative to tree-ish used on right hand side in <tree-ish>:<path> extended SHA-1 syntax. It is usually project root, because when you specify <commit> or <tag> as <tree-ish> it refers to top/root directory of a project.

> 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.

This breaks backward compatibility, hard. And IMHO breaks layers.

But if (big if) it was to be implemented, default behavior should be unchanged, and relative to the cwd (layers!) should use new syntax, for example

     $ cd $GIT/t
     $ git show 570f32266:t/test-lib.sh    # works
     $ git show 570f32266:test-lib.sh      # should not work
     $ git show 570f32266:./test-lib.sh    # should work
     $ git show 570f32266:/t/test-lib.sh   # should perhaps work
 
Currently ":/<text>" (but not "<ref>:/<text>") is taken; see
git-rev-parse(1), "Specifying revisions".

-- 
Jakub Narebski
Poland