Michael Vogt <mvo@xxxxxxxxxx> writes: > Add a --follow-symlinks option that'll resolve symlinks to their > targets when the target is of the form <rev>:<path>. This not only affects "show" but all in the "log" family of commands, because the change is made to revision.[ch] that is shared by them. I doubt that is desirable. I offhand do not think of any command other than "show", to which this feature makes any sense [*1*]. And I certainly do not mind if the feature is limited to "show" and nothing else for that reason. But I do mind the implementation that seeps through to other commands (because "log_init_finish()" is shared with commands in the family other than "show", and because "struct rev_info" is shared across all the commands in the "log" famil) and not limited to "show", which is a sign of typical end-user confusion waiting to happen. Thanks. [Footnote] For example, "git log" is affected by this patch but I am not sure what it even means that we can ask this question: $ git log -p --follow-symlinks -- RelNotes Can we see how each update to Documentation/RelNotes/2.17.0.txt as well as change of RelNotes symlink from 2.17.0.txt to 2.18.0.txt in the patch form? If that were the case, it might make some sense to allow the feature to be triggered by "git log" like your change to builtin/log.c did, but I somehow do not think that is what your patch does.
