Adam Monsen venit, vidit, dixit 14.02.2011 22:50: > Junio C Hamano wrote: >> could you please justify in what workflow it would make sense to use >> -x most of the time? > > Sure. Summary: two long-lived publicly visible branches. > > Details: > Mifos is what I'm usually working on lately. We have branches "master" > and "f-release" both present in our public git repository called "head" > (hosted at sf.net). master is the bleeding edge of development, > f-release is a release maintenance branch recently created off the tip > of master. I expect both to live on forever (even though commits to > f-release will eventually cease). > > Right after f-release was cut, we merged f-release to master every day > or so to make sure bugfixes for f-release were also propagated to future > releases. After a while, merging resulted in too many conflicts and we > started cherry picking instead. > > This process is described generally at > http://mifosforge.jira.com/wiki/display/MIFOS/Release+Branch+Merging+Policy I don't quite understand how cherry picks could conflict less then merges if the release branch contains fixes only. Also, I don't think the advice to use "merge+revert" is a good one. All of this indicates a suboptimal use of branches. My impression is that "f-release" actually mixes release engineering and maintenance. Two possible remedies: - Separate release engineering from maintenance and merge only the latter to master - If you do want them on the same branch "f-release", you probably know beforehand which commits you don't want on master. You can fake-merge these ("merge -Xours") to master and merge the others, which is somewhat ugly but still better than cherry-picking everything. In some sense this is "manual rerere" whose results are shared (pushed) easily.(*) Michael (*) If that is cryptic, I mean something like: git checkout master git merge f-release #be happy if it succeeds, identify problematic commit X if not; decide whether X belongs on master; if yes resolve, if not reset and: git merge X^ git merge -Xours X #back to start -- 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