From: John Tapsell <johnflux@gmail.com>
Date: Tue, 03 Mar 2009 05:01:30 GMT
Subject: Re: proper way to merge?
Message-ID: <43d8ce650903022101x584d7dcfr1758efc5e2c2e5cc@mail.gmail.com>
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F07432@EXCHANGE.trad.tradestation.com>

2009/3/2 John Dlugosz <JDlugosz@tradestation.com>:
> ===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