Re: [PATCH v7 1/1] pull: add ff-only option

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 23, 2020, 23:51 UTC
Message-ID: <CAMP44s3Y3BEbPM_69uxmQWiBq2CqwBo4w13M43WvU4nUQZha8g@mail.gmail.com>
In-Reply-To: <xmqqim9vlkdn.fsf@gitster.c.googlers.com>

On Mon, Nov 23, 2020 at 5:32 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

>
> Alex Henrie <alexhenrie24@gmail.com> writes:
>
> > On Mon, Nov 23, 2020 at 3:46 PM Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>
> >> This patch leaves everything in place to enable this new mode, but it
> >> only gets enabled if the user specifically configures it;
> >>
> >>   pull.rebase = ff-only.
> >
> > Why not use the existing pull.ff=only option instead of adding a new one?
>
> If you have pull.rebase=false, "git -c pull.ff=only pull" would fail
> as desired upon a non-fast-forward.  But if you have
> pull.rebase=true, does it fail the same way (not a rhetorical
> question; I didn't try)?  If so, I agree we do not need a new one.

No. It attempts the rebase, because whatever is set in pull.ff affects only the merge mode. Also, I don't think there's any way to tell git rebase to fail if it's not fast-forward (not that we should attempt the rebase anyway).

> On the other hand, it looks quite funny for that single variable
> that controls the way how pull works, whether rebase or merge is
> used, is pull.REBASE.

Which is precisely why I wanted to rename it to pull.mode.

In my option git pull should have three main modes:

1. fast-forward only
2. merge
3. rebase

The fast-forward only mode can be considered a merge, or a rebase, doesn't matter.

Cheers.

-- 
Felipe Contreras