On 2007-06-17 12:16:35 +0200, Thomas Glanzmann wrote:
> 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@xxxxxxxxxxx
www.treskal.com/kalle
-
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
