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

Linus Torvalds [off-list ref] writes:

On Tue, 18 Dec 2007, Jakub Narebski wrote:

quoted

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.