Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Fri, Jul 29, 2016 at 09:50:55PM -0700, Josh Triplett wrote:
>
>> I would propose the following then:
>> 
>> - I'll write a patch adding a config option format.from, along with
>>   documentation, without changing the default.
>> - The release notes for the version of git introducing that config
>>   option should mention, prominently, the plan to change the default in
>>   a future version of git.
>> - A subsequent release can change the default.  No major rush to do
>>   this.
>> 
>> Does that sound reasonable?
>
> That sounds fine to me.

To me, too.

> I do have to admit that after reading through the "format.*" section of
> git-config(1), there is quite a bit that is configurable in it. So
> perhaps we do not need to be as careful about behavior changes as I
> thought.

I am not sure how the first sentence (which I agree with; a random
user can have quite a different behaviour configured when the
command is run without any option) leads to the conclusion in the
second sentence.  The user can break assumptions made by a tool that
reads format-patch output by tweaking his config but at least he
knows that he changed the configuration, i.e. the breakage can be
explained and attributed to his own action.  The change in the
default is somewhat different.

When we _know_ we are going to be changing the default, we should
forewarn in previous releases (in release notes, and perhaps we
would want to have a runtime warning when the user formats others'
changes without having format.from explicitly set to either true or
false).

So the second step can be delayed and does not have to be done for
the release that includes the first change.  But I am not sure how
"there are many format.* configuration" leads to "we just announce
that we changed the default and tell peole there is a new knob to
retain the original behaviour".

> So if you wanted to squish steps 2 and 3 together, that would also be OK
> by me.