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

From: Bryan Turner <bturner@atlassian.com>
Date: Jul 9, 2019, 20:51 UTC
Message-ID: <CAGyf7-FW-_4AbWE735-=7WjZAaTLHOT_QuWOoHKAjOzZCbWhFA@mail.gmail.com>
In-Reply-To: <CABPp-BGPLxR7NgXRHppLy_W0c=Odhhns2RjcQ4iWKKQMz+SpDQ@mail.gmail.com>

On Tue, Jul 9, 2019 at 1:33 PM Elijah Newren <newren@gmail.com> wrote:

Show 13 quoted lines

>
> On Tue, Jul 9, 2019 at 10:00 AM <usbuser@mailbox.org> wrote:
> >
> > 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?

I think this is something I've seen come up on the list before[1]
(Roland can correct me if I'm wrong). What I've seen asked for before
is the ability to pass the combination "--ff-only --no-ff" and have
that:
* Ensure the branch to be merged is fast-forward from the current
branch (i.e., to ensure no merge commit is actually necessary), but
* Create a redundant merge commit anyway

This retains the ancestry (as in, it shows where the branches were merged), but the merge is always effectively a no-op (no risk of unintended interactions, the sort of subtle breakages where the merge succeeds but the code on each "side" isn't entirely compatible, resulting in broken compilation and/or tests and/or runtime).

Best regards, Bryan Turner

[1] https://public-inbox.org/git/CAP4gbxqjHzqHhPuNK8UOwPMa46g2=vcNSk1AvGjxN8s+ou-0Dw@mail.gmail.com/