Junio C Hamano <gitster@xxxxxxxxx> writes: > Even though I personally think it is an OK longer-term end goal, the > execution looks too hasty. The normal way we handle a big behaviour > change like this is to do the following in steps, in different > releases: > > - In the first release, introduce an early adoptor option (say > log.usemailmap) that can be turned on by the user, but is off by > default. IOW, the initial step is "no change in behaviour, > unless you ask for it". This step also makes sure that the way > to disable it for those who opt into the option from the command > line (i.e. the --no-use-mailmap option) works well. > > - In the second release, when "git log" is run without command line > "--[no-]use-mailmap" and "log.usemailmap" is not set by the user, > give warning about an upcoming flipping of the default, with an > advice message that the user can squelch the warning by setting > the option. > > - In the final release, flip the default and remove the warning. > > Usually there needs sufficient time between the second step and the > third step, so that people will not miss the warning. IIUC, we are between step 1 and step 2. The configuration already exists and uses the safe (i.e. the same as before) default. Your change combines the step 2 and step 3 into one, which will not work. What we need at this point is the "second release" phase, i.e. additional warnings without yet changing the default behaviour. After it is given to the end users and sufficient time passes, we can flip the default.
