Re: [PATCH v2 02/14] pull: improve default warning

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 15, 2020, 11:18 UTC
Message-ID: <xmqqh7on8gia.fsf@gitster.c.googlers.com>
In-Reply-To: <X9ggAxk/z0D9Qom+@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> So I like pull.mode in that sense. But it is also weighed against the
> fact that we'd still have to support pull.rebase, and we'd still have to
> support pull.ff, and explain how those interact with pull.mode (and I
> think any new error in this area must be squelched by those existing
> variables, or it would be a regression for people who already picked
> their default long ago).

I agree that if we were starting from scratch, things would have been much simpler; choose among three ways to reconcile histories (merge, rebase, or ff-only), without adding --[no-]rebase, and allow --[no-]ff only when merging (i.e. things like --ff-only --ff, --no-ff --rebase, would be nonsense combinations). The additional complexity of introducing pull.mode is the primary thing I am hesitant to support it, as we have to design and explain how existing knobs interact with newer one.

> Using advice.* to squelch the advice would be fine with me, provided it
> was _also_ squelched by the existing config options.

Meaning "once you choose between rebase or merge, facing a non-ff history would not trigger the advice message"? I think that is already the case with the released versions of Git, and I think that is a good thing to keep. The advice is only for unconfigured folks who did not tell --[no-]rebase from the command line. One bad thing about it in the released versions is that it would trigger even when the history fast-forwards. The latest round of patches in 'seen' squelches the advice when pulling a fast-forward history even for unconfigured folks as we'd just fast-forward without erroring out.

> Which I think is where your thinking is ending up.

Pretty much.