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

From: Junio C Hamano <[email-masked]>
Date: Sun, 06 Dec 2020 23:34:30 -0800

Elijah Newren <[email-masked]> writes:

> On Fri, Dec 4, 2020 at 8:06 PM Felipe Contreras
> <[email-masked]> 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.