Re: [PATCH] experiment: pull: change --ff-only and default mode

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 7, 2020, 07:34 UTC
Message-ID: <xmqqa6uqcbnd.fsf@gitster.c.googlers.com>
In-Reply-To: <CABPp-BE7B5hn3Fc4zD1o+qoqihJqCut=R1TP_fxMXW42+6iL+w@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 18 quoted lines

> On Fri, Dec 4, 2020 at 8:06 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
> This commit message should say something more than just "change x", it
> should have some words about what it is change from or to.  I think
> the thrust of the patch is allowing --ff-only, --merge, and --rebase
> to countermand an earlier otherwise-conflicting option.  Perhaps a
> commit message of the form:
>
> In git, we sometimes allow conflicting command line options with the
> last one winning, e.g.
>   git log --patch --no-patch
>   git log --no-patch --patch
> other times we just error out when conflicting options are given, e.g.
>   git checkout -b --orphan NEWBRANCH
>   git checkout --orphan -b NEWBRANCH
> Previously, we did neither with --no-ff, --merge, and --rebase.
> Change these options to have a last-one-wins behavior.

If the choices are clearly among --ff-only, --merge and --rebase, I am fine with the last-one-wins change, and your explanation does make sense.

I however am not sure how --no-ff and other --ff=<how> friends should interact with the primary two choices. --ff=no is used by those who want to merge, so "--merge --ff=no" combination is a sensible thing to accept. The same can be said for "--merge --ff" (fast-forward when able). It is interesting to realize that it would not be wrong to say "--rebase --ff" even. When their history we are rebasing our own work on top is a descendant of our history, such a rebase operation ends up in fast-forwarding to their tip.