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

From: Elijah Newren <newren@gmail.com>
Date: Jul 9, 2019, 16:35 UTC
Message-ID: <CABPp-BHpkcOSkTrNDPGWRgSJgbqkc0PRqMqmesg7tQdS5TfMDA@mail.gmail.com>
In-Reply-To: <1152121968.7459.1562688927235@office.mailbox.org>

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