Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html