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

Elijah Newren [off-list ref] writes:

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