Junio C Hamano wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
> >>     - With the endgame of "out of box Git without any configuration
> >>       refuses 'git pull' (without --merge/--rebase) that does not
> >>       fast forward" in mind, start warning "In the future you will
> >>       have to either set pull.mode (and/or its friends) or type
> >>       "pull --merge" (or "pull --rebase") when the endgame version
> >>       of 'git pull' would fail with the error message, but still do
> >>       as was asked to do as before.  At this step, existing users
> >>       can set pull.mode to "merge" or "rebase" or whatever to
> >>       squelch the warning.
> >> 
> >>     - Flip the default.  By the time this happens, thanks to the
> >>       previous step to warn beforehand, nobody needs to see the
> >>       warning. (your step 4)
> >
> > This is what my last version of the series did[1]. However, my plan was
> > to land this in 1.x so users could see the warning, and then flip the
> > switch on 2.0.
> >
> > This plan, however, fell off the cliff.
> Yeah, I see that $gmane/234488 explains why the second step in the
> previous one stopped.  I guess it was in expecting a reroll state,
> waiting for that other topic (I do not remember offhand) to
> graduate.
> I see nothing touching the affected codepaths now, so this time
> around we may have a better chance, perhaps?

A chance of what? Do you want me to reroll to include the future
backwards-incompatible change warning? Should I include the patch that
turns the switch?

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to