On Tue, Jul 9, 2019 at 10:00 AM <usbuser@xxxxxxxxxxx> wrote: > > > On 09 July 2019 at 18:35 Elijah Newren <newren@xxxxxxxxx> wrote: > > ... > > Hope that helps, > > Elijah > > I hope this is not-top-posting? I'm new to this and know nothing apparently. Yep, you're doing good. > 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? We can't break backward compatibility, so we can't change the meaning of the existing flags. However, I have no idea what you want this new flag to do; what is the behavior you want? The only three possibilities I can think of are what the three flags we are currently discussing do. > 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. You've lost me again, I think. You expect --ff-only to only perform a check, i.e. to not update anything and thus only report on whether a fast-forward would be possible, but leave the branch exactly where it started no matter what? Or is it just still not clear that a fast forward by definition is not "a real merge", i.e. it means to update using a mechanism that doesn't involve creating any new commits? Elijah