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

From: Alex Henrie <alexhenrie24@gmail.com>
Date: Nov 23, 2020, 22:03 UTC
Message-ID: <CAMMLpeS2e2dFjPHC7N5O67QTo48cpvWEHiU8E55w9YYP4MU0MQ@mail.gmail.com>
In-Reply-To: <X7wuMvHRURK1QS/Q@coredump.intra.peff.net>

On Mon, Nov 23, 2020 at 2:48 PM Jeff King <peff@peff.net> wrote:

Show 21 quoted lines

>
> On Mon, Nov 23, 2020 at 02:34:18PM -0600, Felipe Contreras wrote:
>
> > > > Which is why I suggested to make fast-forward-only the default:
> > > >
> > > > https://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/
> > > >
> > > > In what case would that default not be what most people want?
> > >
> > > Well, it *was* the default, previously, IIRC.
> >
> > There has never been a "pull.mode=ff-only" option; that's what I tried
> > to introduce.
>
> There is pull.ff=only these days, which also squelches the message. But
> you're right that it was never the default.
>
> 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.

> I don't recall whether there is any active plan to move away from the
> merge default, though.

There's no formal plan yet. I didn't want to propose anything until people had gotten used to explicitly setting the reconciliation strategy. However, it has been on my long-term radar ever since the warning was added.

-Alex