Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@xxxxxxxxx>
>
> The interaction of rebase and merge flags and options was not well
> tested. Add several tests to check for correct behavior from the
> following rules:
> * --ff-only takes precedence over --[no-]rebase
> * Corollary: pull.ff=only overrides pull.rebase
> * --rebase[=!false] takes precedence over --no-ff and --ff
> * Corollary: pull.rebase=!false overrides pull.ff=!only
> * command line flags take precedence over config, except:
> * --no-rebase heeds pull.ff=!only
> * pull.rebase=!false takes precedence over --no-ff and --ff
This is wrong, --ff-only is meant only for merge, not rebase.
You are testing for behavior that 1) has not been agreed to, and 2) is
not documented.
This is what the current documentation says about all the --*ff*
options:
--ff::
--no-ff::
--ff-only::
Specifies how a merge is handled when the merged-in history is
already a descendant of the current history. `--ff` is the
default unless merging an annotated (and possibly signed) tag
that is not stored in its natural place in the `refs/tags/`
hierarchy, in which case `--no-ff` is assumed.
+
With `--ff`, when possible resolve the merge as a fast-forward (only
update the branch pointer to match the merged branch; do not create a
merge commit). When not possible (when the merged-in history is not a
descendant of the current history), create a merge commit.
+
With `--no-ff`, create a merge commit in all cases, even when the merge
could instead be resolved as a fast-forward.
+
With `--ff-only`, resolve the merge as a fast-forward when possible.
When not possible, refuse to merge and exit with a non-zero status.
--
Felipe Contreras
