Re: [PATCH] Support ent:relative_path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dana How wrote:
> On 5/4/07, Junio C Hamano <junkio@xxxxxxx> wrote:
>> Jakub Narebski <jnareb@xxxxxxxxx> writes:

>>> 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
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]