"Antonin Godard" <antonin.godard@xxxxxxxxxxx> writes:
> This is what the documentation seems to imply, but builtin/log.c uses these
> configuration variables in git_log_config(), for example. In the same file,
> cmd_show() uses git_log_config().
"imply"? The documentation says so because the command was designed
to work like so when the feature was added in mid 2022.
34bc1b10 (format-patch: allow forcing the use of in-body From: header, 2022-08-29)
d5fc07df (format-patch: learn format.forceInBodyFrom configuration variable, 2022-08-29)
Please refrain from using words that imply value-judgement from your
analysis and stick to the facts; I'll try to do so in my messages,
too.
As the log family of commands happen to share much of the
implementation, their code paths pass the log-config structure which
is a mixed bag. It does not necessarily mean all commands in the
family use all the members in the structure.
> With this reasoning in mind, I thought "git show --format=email" should also
> benefit from the format.from and format.forceInBodyFrom variables, to correctly
> display the output.
"correctly"?
Changing the behaviour retroactively would mean that those who have
been relying on the fact that in-body header configuration meant for
"git format-patch" does not affect "git log" would suddenly start to
see their output differently. So I'd worry how bad the downside
would be.
Having said all that.
In hindsight, or if we pretend we were in 2005 and starting the
project again from scratch, if we did not have any "format.*"
configuration variables and instead all of these were "log.*", I'd
agree with everything you said in the message I am responding to.
In such a hypothetical world, we may not even have added a separate
"format-patch" command, but used "git log" with an option to spit
out its output into an individual file for every commit.
