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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 30, 2015, 20:05 UTC
Message-ID: <xmqqoam5xtyj.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqegn1z9fp.fsf@gitster.dls.corp.google.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.