On Tue, Jul 9, 2019 at 10:00 AM <usbu...@mailbox.org> wrote: > > > On 09 July 2019 at 18:35 Elijah Newren <new...@gmail.com> 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
