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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:44

David Turner [off-list ref] writes:
quoted
 * 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?


	

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

From: David Turner <hidden>
Date: 2016-06-15 23:04:44

On Tue, 2015-05-12 at 13:07 -0700, Junio C Hamano wrote:
David Turner [off-list ref] writes:
quoted
quoted
 * 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.  Or maybe
sub/link was actually a link to ../outlink, and ../outlink was a link
to ../nextlink. 

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


[1] http://www.spinics.net/lists/git/msg250893.html
xmqqd225fsw8.fsf@gitster.dls.corp.google.com 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help