From: usbuser@mailbox.org Date: Wed, 10 Jul 2019 07:49:16 GMT Subject: Re: Unexpected or wrong ff, no-ff and ff-only behaviour Message-ID: <1837375396.9386.1562744956530@office.mailbox.org> In-Reply-To: > On 09 July 2019 at 22:51 Bryan Turner wrote: > > On Tue, Jul 9, 2019 at 1:33 PM Elijah Newren wrote: > > > > On Tue, Jul 9, 2019 at 10:00 AM 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/ This is exactly what I was expecting/wanting, thanks for clarifying.