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

From: Elijah Newren <newren@gmail.com>
Date: Jul 9, 2019, 20:33 UTC
Message-ID: <CABPp-BGPLxR7NgXRHppLy_W0c=Odhhns2RjcQ4iWKKQMz+SpDQ@mail.gmail.com>
In-Reply-To: <275487563.12198.1562691633735@office.mailbox.org>

On Tue, Jul 9, 2019 at 10:00 AM <usbuser@mailbox.org> wrote:

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