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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
