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

From: Felipe Contreras <[email-masked]>
Date: Tue, 15 Dec 2020 06:53:41 -0600

Junio C Hamano wrote:
> Jeff King <[email-masked]> writes:
> 
> > 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.

I have already tried all the options.

If we go through a deprecation period (which I insist we must), the
options are these:

 1. Change the semantics of --ff-only (breaks backwards-compatibility)
 2. Add a "pull.rebase=ff-only" option (very weird)
 3. Add a "pull.mode" configuration (tons of advantages)

Yes, we have to map the modes to the existing knobs, but it's not complex:

 * pull.rebase = false  <=> pull.mode = merge
 * pull.rebase = true   <=> pull.mode = rebase
 * pull.rebase = *       -> pull.mode = rebase

That's it. We don't even have to map --ff-only (which has different
semantics anyway).

Cheers.

-- 
Felipe Contreras