Elijah Newren <newren@xxxxxxxxx> writes: > On Fri, Dec 4, 2020 at 8:06 PM Felipe Contreras > <felipe.contreras@xxxxxxxxx> 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.
