2009/3/2 John Dlugosz <JDlugosz@xxxxxxxxxxxxxxxx>: > ===Re:=== > Instead of merge, I prefer to rebase. so: > > git checkout dev > git rebase origin rel > > This replays each commit made in 'dev' on top of release, letting you > fix each commit separately. It also means that when I commit to > release, the changes are a nice tree. > ===end=== > > The reason I'm doing this -- why I took over maintenance of the repository -- is because I strenuously objected to his plan to "rebase". NO! Merge, don't rebase. Besides never rebasing published branches, in this case it works much better the other way around: dev made systemic changes, and rel is mostly patches and completely new pieces of code. After looking at what was in dev..rel and what was in rel..dev, I chose to start with dev and bring in the commits from rel in a controlled manner. It depends on what you're doing :-) I find that if the branch is too large to easily rebase, then it's probably too large entirely :) Developers don't like master to change in large ways suddenly - makes it hard for all the other branches. It also makes it impossible to bisect, something that I find essential. If you are combining two trees which are too big to easily rebase, then there's a high chance that something will break either due to their individual changes or because of a mistake while merging. In such a case, it's then impossible to bisect to try to pinpoint the actual problem. It will be interesting to hear your view on merging vs rebasing after a year or so of trying both. John -- 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
