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

[David Turner <dturner@twopensource.com>]

On Tue, 2015-05-12 at 14:42 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > On Tue, 2015-05-12 at 13:07 -0700, Junio C Hamano wrote:
> >> David Turner <dturner@twopensource.com> 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.

No.  Successfully resolved out-of-tree symlinks must be relative to the
tree root.  Jeff King and I discussed this in the original RFC:
otherwise, after a chain of symlinks which might move you all over the
tree, you have no idea what "../" is relative to.