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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> 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.