On Dec 18, 2007 2:20 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx +1 650 804 5991 cell
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
