> On 09 July 2019 at 18:35 Elijah Newren <new...@gmail.com> wrote: > > > Hi Roland, > > On Tue, Jul 9, 2019 at 9:17 AM Roland Jäger <eyen...@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
