Hi Roland, On Tue, Jul 9, 2019 at 9:17 AM Roland Jäger <eyenseo@xxxxxxxxxxx> 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
