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 29, 2008, 04:38 UTC
Message-ID: <20080729043839.GC26997@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.1.00.0807290123300.2725@eeepc-johanness>

On Tue, Jul 29, 2008 at 01:27:44AM +0200, Johannes Schindelin wrote:

Show 7 quoted lines

> > 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.

Perhaps. But I see this as an operation on the production branch: "pull in master's changes, forgetting ours". In your workflow (git checkout master && git merge -s ours production && git push origin master:production) we perform an operation on master, which doesn't seem as intuitive to me.

Not to mention that we might not _control_ master. What about (and I think Sverre mentioned something like this previously):

 I forked the kernel and made some changes. Some of my changes got
 applied upstream. The others are now obsolete. Now I want to bring
 myself in sync with Linus, but I want to keep my history (either
 because the history is interesting to me, or because others are basing
 their work on it).

Then your workflow, while still possible within the local repository, means you are munging the "linus" branch, which seems wrong. That branch is probably even just a tracking branch, which you would not want to build on, anyway.

-Peff