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]
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html