Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
- From
Jeff King <peff@peff.net>
- Date
- Jul 28, 2008, 19:26 UTC
- Message-ID
- <20080728192651.GA26677@sigill.intra.peff.net>
- In-Reply-To
- <alpine.DEB.1.00.0807282008470.8986@racer>
On Mon, Jul 28, 2008 at 08:09:55PM +0100, Johannes Schindelin wrote:
Show 5 quoted lines
> 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