Show 35 quoted lines
> On 09 July 2019 at 22:51 Bryan Turner <bturner@atlassian.com> wrote:
>
> On Tue, Jul 9, 2019 at 1:33 PM Elijah Newren <newren@gmail.com> wrote:
> >
> > 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/