Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy

[Jeff King <peff@peff.net>]

On Mon, Jul 28, 2008 at 08:09:55PM +0100, Johannes Schindelin wrote:

> Well, I have to say that the workflow is a bit backwards if the person who 
> _publishes_ the thing is the one saying "Ooops, my version no goodie, 
> other version please, but so that pull still works".
> 
> I would have expected the one who has the good version to make the choice.

My situation was two long-running branches, "stable" and "devel",
both of which were worked on by many developers. One person was in
charge of integration and branch management. They wanted "stable" to
get the contents of "devel" (which were now ready for release), ignoring
any small fixes that had been done on "stable" (since they had all been
moved over to "devel" previously, but in subtly different ways that
would create conflicts). And "git reset" was not an option, because they
wanted to keep the history of "stable" in case those fixes needed to be
looked at later.

So the logical sequence was:

  git checkout production
  git merge -s theirs master

-Peff