Re: proper way to merge?

2009/3/2 John Dlugosz [off-list ref]:

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