> On 09 July 2019 at 22:51 Bryan Turner <btur...@atlassian.com> wrote: > > On Tue, Jul 9, 2019 at 1:33 PM Elijah Newren <new...@gmail.com> wrote: > > > > On Tue, Jul 9, 2019 at 10:00 AM <usbu...@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-...@mail.gmail.com/
This is exactly what I was expecting/wanting, thanks for clarifying.
