On 7/28/08, Jeff King <peff@xxxxxxxx> wrote: > 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 I have to say, this somehow feels wrong to me. What you're saying is essentially that "stable has already been merged into devel" followed by "and now we want to catch stable up to devel." It really is two separate thoughts, and merging devel directly into stable - literally by *undoing* all the changes from stable - doesn't sound like it should be considered a safe operation. Personally, I've started enjoying the "--no-ff" option to git-merge. That way I can do git checkout master git merge production git checkout production git merge --no-ff master The latter merge isn't really a "merge" since it could have been just fast forwarded. But it avoids the aesthetic problems of commits like "merge production into master" showing up in the master branch. It also means that "git reset --hard HEAD^" works whether or not a fastforward would have been theoretically possible. Of course, this whole discussion is really just about how to make your log look cleaner, and we could debate forever about that. It may make sense to simply provide "theirs" as an exact mirror of "ours" if only in the name of symmetry. Have fun, Avery -- 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
