From: Dana How <danahow@gmail.com>
Date: Tue, 18 Dec 2007 22:30:40 GMT
Subject: Re: log/show: relative pathnames do not work in rev:path
Message-ID: <56b7f5510712181430w798d4a65x20a24f061c5d0eb6@mail.gmail.com>
In-Reply-To: <7vejdjy79y.fsf@gitster.siamese.dyndns.org>

On Dec 18, 2007 2:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > 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