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

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, 18 Dec 2007, Jakub Narebski wrote:
>> 
>> 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.
>
> Indeed.
>
> The <treeish>:<path> syntax *is* relative, but it's relative to the exact 
> *treeish* that is given. It has nothing what-so-ever to do with the 
> current working directory, since the user has explicitly given an exact 
> tree object, and trying to fake that out would be actively wrong.
>
> That said, I can kind of understand the wish for something like this, and 
> I suspect that we could make the "commit->tree" translation take the 
> current path into account. In other words, maybe we should have something 
> like this:
>
> 	/*
> 	 * This sequence currently works
> 	 */
> 	[torvalds@woody git]$ git rev-parse HEAD
> 	f9c5a80cdf2265f2df7712fad9f1fb7ef68b4768
>
> 	[torvalds@woody git]$ git rev-parse HEAD^{tree}
> 	051fb0c0dff4371f97f8ad9407f9f1fd335b1682
>
> 	[torvalds@woody git]$ git rev-parse HEAD^{tree}:t
> 	49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
> 	/*
> 	 * .. but this would be new
> 	 */
> 	[torvalds@woody git]$ cd t
> 	[torvalds@woody t]$ git rev-parse HEAD^{tree}
> 	49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
> where the magic is *not* done by any "SHA1 path lookup" at all, but is 
> simply done by the commit->tree lookup. At least at that point it would 
> make logical sense (although it would probably be quite painful to 
> implement).

It is not just painful to implement.

Although I can buy that purely from the user (read: people who do not
know how the world works) experience point of view, you have to be extra
careful if you do this.  There are existing codepaths that take a string
that names a treeish from the end user, appends "^{tree}" to that
string, and passes the result to get_sha1() to obtain a tree object name
they want to operate on (the alternative is parse_tree_indirect() but it
forces them to go through the object layer).  You will need to update
these callers to keep them working from subdirectories.