On merging strategies, fast forward and index merge

I recently read Junio's description of how to dig oneself out of a hole using `git merge -s ours' (I'm learning to use the space...), and I've realised there's a problem here.

The `ours' merge strategy is meant to create a merge commit whose tree is in every way identical to that of the starting commit. But `git merge' won't always do this, because it doesn't always invoke the strategy program.

Consider the command `git merge -s ours MESSAGE MASTER FAILED'.

  * If we've not actually messed with our MASTER since the FAILED branch
    departed, then MASTER is actually an ancestor of FAILED, and `git
    merge' will unhelpfully fast-forward us to the tip of the FAILED
    branch.  Instead of leaving the merge result like MASTER, it's made
    it entirely the wrong thing!

  * If both MASTER and FAILED have made changes, but to different files,
    then `git merge' will try an index-level merge, find that it
    succeeds, and leave us with a mixture of MASTER and FAILED files.
    Which is (in this case) entirely what we didn't want.

Additionally, it occurs to me that the fast-forwarding behaviour isn't always what I want anyway. Consider a merge of a topic branch:

  `git merge MESSAGE MASTER TOPIC'

If I allow fast-forward, I lose information about where the topic started and ended. This is a shame, particularly if I find other places I want to apply those changes (either as a string of similar commits, or squidged into a single one) onto other branches.

Because code speaks louder, I'll follow-up this article with a suggested patch.

-- [mdw]