Re: Pick the right default and stop warn on `git pull`

From: Jeff King <peff@peff.net>
Date: Nov 24, 2020, 00:37 UTC
Message-ID: <X7xV5SyvCi3ojYz6@coredump.intra.peff.net>
In-Reply-To: <CAMMLpeS2e2dFjPHC7N5O67QTo48cpvWEHiU8E55w9YYP4MU0MQ@mail.gmail.com>

On Mon, Nov 23, 2020 at 03:03:07PM -0700, Alex Henrie wrote:

Show 9 quoted lines

> > The default has continued to be merging. If we were going to switch that
> > to bailing out and doing nothing with a warning, I agree that doing so
> > only in the non-fast-forward case would be much better (because in that
> > case, all three modes have the same result).
> 
> I'd be fine with making fast-forward-only the default. But then again,
> some users like to set pull.ff=no, which creates a merge commit even
> when fast-forwarding is possible. The existence of that workflow might
> be a good reason to require the user to always be explicit.

Good point. I was thinking there was no option the users could set where they'd be disappointed by a fast-forward, and for all other cases we'd stop and ask the user to tell us more explicitly what they want. But you're right that pull.ff=no is an exception there.

It might still be OK to allow it by default, though as we have always allowed a fast-forward merge by default. So this would be a strict tightening from the long-standing behavior of "if fast-forward, do that; otherwise, merge" to "if fast-forward, do that; otherwise punt". Anybody who wants pull.ff=no already had to configure it.

-Peff