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/
