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

[Elijah Newren <newren@gmail.com>]

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