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

"Dana How" [off-list ref] writes:

How about this:
<tree-ish>:./path -> NEW: relative

I think making "<tree>:./" mean "replace ./ with the current prefix and
retry the usual expansion" is relatively confusion free.  You have to
work hard to confuse yourself:

	d=$(git rev-parse --verify HEAD:Documentation)
        git rev-parse "$d":./howto ;# would not work
	cd Documentation && git rev-parse "$d":./howto ;# would work

<tree-ish>:../path -> NEW: relative

I would rather avoid up (../) processing if we can, but making "<tree>:"
immediately followed by 1 or more "../" mean "take the current prefix,
strip away the same number of trailing directory components as we have
"../" there, and tuck the remainder in front of the path before trying
the usual expansion" would be a natural and relatively confusion free
extension of the above.  I think I can live with that, too.

<tree-ish>:?pattern -> NEW: same as next (current :/ )

I'd prefer keeping :? (or some other unlikely-in-path letter other than
'?') as a special extension introducer character, i.e. leaving the door
open to:

	<tree>:?(magic)parameter

whose semantics is to be defined later, depending on "magic".

Similarly, we could do the same for

	:?(magic)parameter

<tree-ish>:/pattern -> unchanged (sha1_name_oneline IIRC)

I do not think this is oneline.  "<commit>:/pattern" could be a natural
extension to the current ":/pattern" that instructs "dig from only this
commit, not all refs, and find a commit with the oneline," but I do not
think it is a good idea.  It is too similar to "locate this tree entry
from the given tree" syntax.

<tree-ish>:path -> unchanged: absolute

Absolutely ;-)