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