Michael Vogt <m...@ubuntu.com> 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.
