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

Jeff King [off-list ref] writes:

On Fri, Jul 29, 2016 at 09:50:55PM -0700, Josh Triplett wrote:

quoted

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.

On Mon, Aug 01, 2016 at 10:35:22AM -0700, Junio C Hamano wrote:

quoted

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.

I half-agree. Config that causes unpredictable behavior can break
somebody else's script that you are running. If you say "oh, I guess I
shouldn't set that config" and move on with your life, then the config
hasn't really hurt anybody. If you complain to the script author that
their script is broken, and insist that they pass the --no-foo option,
then the script writer does not care much whether it was a config option
or a change of default.

-Peff

PS We also changed the default pager behavior for format-patch recently,
   though I can't actually think of any script regressions that would
   cause, since it only kicks in when output is going to the tty.