Re: log/show: relative pathnames do not work in rev:path
- From
- Dana How <danahow@gmail.com>
- Date
- Dec 18, 2007, 22:30 UTC
- 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:
Show 16 quoted lines
> 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