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

[usbuser@mailbox.org]

> On 09 July 2019 at 18:35 Elijah Newren <newren@gmail.com> wrote:
> 
> 
> 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

I hope this is not-top-posting? I'm new to this and know nothing apparently.

If I were to write a patch then I would very much prefer to implement the behaviour that I expected and want to exist - either by a new flag and fixed wording, or just fixed behaviour. I guess the latter is a no go. Could you point me in the right direction where I would need to start to add such a flag?

Additionally I would also want to change the wording for --ff-only, as it currently reads as if it only performs a check (which would lead to the expected behaviour) but does more than that, as it prevents "real merges" altogether.

Thank you for your time,
Roland