Re: merge into branch currently not active / checked out

From: Karl Hasselström <kha@treskal.com>
Date: Jun 20, 2007, 07:54 UTC
Message-ID: <20070620075446.GA30186@diana.vm.bytemark.co.uk>
In-Reply-To: <20070617101635.GK23473@cip.informatik.uni-erlangen.de>

On 2007-06-17 12:16:35 +0200, Thomas Glanzmann wrote:

Show 5 quoted lines

> the problem is. Getting a patch into mutt takes several years. At
> least it took for the hcache. So what I do is keep my patches
> up2date on top of there HEAD. So I prefer topic branches. And my
> patches throw _once_ in 4 years a conflict that was not
> automatically resolved. I used bitkeeper before, now I use git.

For this use case, I'd say rebasing is the right thing to do -- otherwise you accumulate a 4-year-long history of uninteresting merges, as Junio warned.

There are two cases where rebasing is worse than a "real" branch that's merged instead of rebased:

  1. Other people base their work on yours, and need to be able to
     pull. They want a stable foundation to build on, one that doesn't
     move.

  2. Your work is large enough that it's too much work to rebase it.
     (This also implies that when you merge, you get interesting
     conflicts, since for the case of autoresolved conflicts, rebasing
     isn't that much more expensive than merging.)

Since you describe your work as "a patch", I'm guessing neither excuse applies to you. :-)

> I don't push my work other than in patches that is, so I am going to
> give it a try. I always wanted to try rebase, but I never actually
> did try it.

<advertisement>
  You could also try StGIT. Rebasing a patch series on top of a git
  branch is what it does.
</advertisement>

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle