Subject: Re: [PATCH v5 3/3] cat-file: add --follow-symlinks to --batch

From: Junio C Hamano <[email-masked]>
Date: Tue, 12 May 2015 14:42:47 -0700

David Turner <[email-masked]> writes:

> On Tue, 2015-05-12 at 13:07 -0700, Junio C Hamano wrote:
>> David Turner <[email-masked]> writes:
>> 
>> >>  * I am not sure if HEAD:link that points at HEAD:link should be
>> >>    reported as "missing".  It may be better to report the original
>> >>    without any dereferencing just like a link that points at outside
>> >>    the tree? i.e. "symlink 4 LF link".
>> >
>> > Unfortunately, a symlink loop might include relative symlinks
>> > (e.g. ../a).  If we return a relative symlink, the user will
>> > not be able to distinguish it from a non-loop, out-of-tree symlink.  So
>> > I think we may not return symlink 4 LF ../a for these cases.  
>> 
>> I do not follow.  Let's start from a shared example.
>> 
>>     HEAD:sub/link is a symbolic link whose value is ../nextlink
>>     HEAD:nextlink is a symbolic link whose value is sub/link
>> 
>> That's a loop.  Now, I think what I am sugesting is
>> 
>> 	$ git cat-file --batch-check --follow-symlinks <<\EOF
>> 	HEAD:sub/link
>>         HEAD:nextlink
>> 	EOF
>> 	symlink ../nextlink
>>         symlink sub/link
>> 
>> If you asked about sub/link and then got ../nextlink back, then
>> isn't it clear for the reading script that it is about nextlink
>> at the top-level?  Why can't it tell it from out-of-tree link?
>
> Because maybe sub/link was actually a link to ../../nextlink.

Then the output would have said "symlink ../../nextlink" and you can
tell these two cases apart, no?  Same for the other case.

> But I think I'm OK with implementing your proposed solution[1] of
> categorizing all of the possible cases.

I think that is the cleanest I can come up with offhand, and would
give the easiest input to scripters.  At least I think so for now,
but others may have even better ideas ;-)

Thanks.