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