Thread (1 message) 1 message, 1 author, 2016-06-15

Re: RFC: git cat-file --follow-symlinks?

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

Junio C Hamano [off-list ref] writes:
... In other words, ^{resolve} that is not followed by a
colon and path is something entirely different from what we have
been discussing.
Having said that, I am not saying that such an alternative "follow
symbolic links in many other places" is a worthless suggestion.

It just does not work as an extended SHA-1 syntax.

    git rev-parse HEAD^{resolve}:RelNotes HEAD:Documentation

would make sense; RelNotes, if it were a symbolic link, is resolved,
while Documentation will never be.  On the other hand

    git log next^{resolve} master -- Documentation

will not make any sense, as it is a totally conflicting request.
Does it resolve symlinks only when encountering a commit that the
traversal that started from 'next' happened to have reached before
the traversal from 'master' got there?  What should happen for
commits that are reachable from both?

So even if (and this is a big if) such an "aggressive symlink
following" mode were useful for some commands, I think the switch
belongs to the command, not the per-object syntax.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help