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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 28 Jul 2008, Jeff King wrote:

> 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