Re: Unexpected or wrong ff, no-ff and ff-only behaviour

[Elijah Newren <newren@gmail.com>]

Hi Roland,

On Tue, Jul 9, 2019 at 9:17 AM Roland Jäger <eyenseo@mailbox.org> wrote:
>
> Thanks for answering Junio.
>
> I get what git does. But I believe that either the documentation ist wrong/ambiguous or --no-ff and --ff-only should be able to be combined and either should be fixed - preferably the later. What I want to say to git is "I never accept a real merge; please make a merge commit, even if it is redundant/empty". And I believe that github and gitlab allow to configure something like that.

Please don't top-post on this list.

I agree, the documentation is wrong or misleading and there is a
wording change we could make to improve it.  But, in particular,
--no-ff and -ff-only are completely incompatible.  A fast forward
implies no commits of any kind are created, while --no-ff explicitly
requires one to be created.  More on that below...

> My manpage tells me the following:
>
> --ff When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default behavior.
> => Allow either

Yes.

> --no-ff Create a merge commit even when the merge resolves as a fast-forward. This is the default behaviour when merging an annotated (and possibly signed) tag that is not stored in its natural place in refs/tags/ hierarchy.
> => Always create a commit, even when FF

Not quite; I'd instead say:

=> Always create a merge commit, even if FF is instead possible.

In particular, FF means there is no commit creation.  I agree the
documentation needs correction here, it should be:

"--no-ff: Create a merge commit even when the merge could instead
resolve as a fast-forward..."

Would you like to try your hand at submitting a patch with this change?

> --ff-only Refuse to merge and exit with a non-zero status unless the current HEAD is already up to date or the merge can be resolved as a fast-forward.
> => Fail if FF is not possible

Yes.


Hope that helps,
Elijah