Re: [PATCH] Support ent:relative_path

From: Jakub Narebski <jnareb@gmail.com>
Date: May 5, 2007, 01:06 UTC
Message-ID: <200705050306.32345.jnareb@gmail.com>
In-Reply-To: <56b7f5510705041752o74b59284x872480e4413f83ab@mail.gmail.com>

Dana How wrote:

> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:

Show 19 quoted lines

>>> I'm not sure about "<tree-ish>:<path>" with <path> being relative by
>>> default. For me it is <path> in <tree-ish> (like in
>>> "git-ls-tree -r <tree-ish>" result).
>>
>> That's right (and Dscho is also).
>>
>> "v1.5.1:git.c" IS "git.c that appears at the toplevel of
>> v1.5.1's tree."
>>
>> Ok, for now let's forget about this relative stuff.
> 
> Hmm, most of the work I do in the parts of our
> perforce repository I want to convert to git is
> far enough down that the paths have 6 in-repo path components.
> I don't want to type all those when I want to fetch an
> older version with git-show.  Everything I do is relative.
> In fact,  I think perforce supports typing absolute paths,
> (using an 8-character prefix!) but I have never used it,
> nor would I if it were shorter.

I think the consensus is to use <tree-ish>:./<relative-path> for relative paths, and <tree-ish>:<path> for absolute (well, in the meaning that it counts from top of _tree-ish_, and tree-ish needs not to be top tree / commit tree).

And I think 6 in-repo path components means not very well thought directory hierarchy, I think...

-- 
Jakub Narebski
Poland