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.

On Dec 18, 2007 2:20 PM, Junio C Hamano [off-list ref] wrote:

Linus Torvalds [off-list ref] writes:

quoted

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.

Thanks,  I didn't know about those "^{tree}" codepaths.

How about this:
<tree-ish>:./path -> NEW: relative
<tree-ish>:../path -> NEW: relative
<tree-ish>:?pattern -> NEW: same as next (current :/ )
<tree-ish>:/pattern -> unchanged (sha1_name_oneline IIRC)
<tree-ish>:path -> unchanged: absolute
This shouldn't need to know if tree-ish references a commit or not.

Someday later,  the last 2 cases could be changed to be more
like the Unix command line if desired.  This is very similar to
Junio's response last May (by memory).

Typing an extra "./" is a big improvement over a long path prefix.

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell

Hi,

On Tue, 18 Dec 2007, Dana How wrote:

[lots about rev:path taking path to be relative to the project root, 
 preferring it to be relative to the current prefix instead]

Typing an extra "./" is a big improvement over a long path prefix.

Have you tried the path completion?

Alternatively, I suggest making a script

	$ cat > $HOME/bin/git-showrel << \EOF
	#!/bin/sh
	git show "$(echo "$1" | sed "s|:|:$(git rev-parse --show-prefix)|")"
	EOF
	$ chmod a+x $HOME/bin/git-showrel

Then

	$ git showrel HEAD:file

will do what you want.

(An alias will not work, since the cwd will be the project root.)

Hth,
Dscho

P.S.: I just tried "git show HEAD~20:<filename with : in it>" and it did 
not work...  I consider this a more serious issue than the relative path 
one.