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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 28, 2008, 23:27 UTC
Message-ID: <alpine.DEB.1.00.0807290123300.2725@eeepc-johanness>
In-Reply-To: <20080728192651.GA26677@sigill.intra.peff.net>

Hi,

On Mon, 28 Jul 2008, Jeff King wrote:

Show 23 quoted lines

> 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

To me, this suggests that they were too married to 'production' being the "dominant" branch.

Thing is: they had two branches. They should be merged, but one should prevail: 'master'.

So if I have two branches, say "x" and "y", and I want to merge them, but really throw away the tree of "x", I would check out 'y', naturally. Then 'git merge -s ours x'.

If the result should become the state of 'x', too, I would then just 'git push origin y:x'.

Maybe I am "Git-braindead" by now, so that you can make fun of me like I used to make fun of CVSers and SVNers...

Ciao, Dscho