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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jul 11, 2019, 15:46 UTC
Message-ID: <20190711154636.GJ9224@genre.crustytoothpaste.net>
In-Reply-To: <CAGyf7-FW-_4AbWE735-=7WjZAaTLHOT_QuWOoHKAjOzZCbWhFA@mail.gmail.com>

On 2019-07-09 at 20:51:39, Bryan Turner wrote:

Show 13 quoted lines

> 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).

I should point out that this is scriptable using something like the following:

  git fetch origin topic && git merge-base --is-ancestor HEAD FETCH_HEAD && \
    git merge --no-ff FETCH_HEAD

or, if you're just merging a branch:

  git merge-base --is-ancestor HEAD topic && \
    git merge --no-ff topic

While I agree it's not as convenient as having this built-in (and I understand why people want it), it is achievable with an alias without much difficulty.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204