rebase-with-history -- a technique for rebasing without trashing your repo history

[Michael Haggerty <mhagger@alum.mit.edu>]

Sorry to cross-post, but I think this might be interesting to all three
projects...

I've been thinking a lot about the problems of tracking upstream changes
while developing a feature branch.  As I think everybody knows, both
rebasing and merging have serious disadvantages for this use case.
Rebasing discards history and makes it difficult to share
work-in-progress with others, whereas merging makes it difficult to
prepare a clean patch series that is suitable for submission upstream.

I've written some articles describing another possibility, which
combines the advantages of both methods.  The key idea is to retain
rebase history correctly, on a patch-by-patch level.  The resulting DAG
retains enough history to prevent problems with merge conflicts
downstream, while also allowing the patch series to be kept tidy.

(Please note that this technique only works for the typical "tracking
upstream" type of rebase; it doesn't help with rebases whose goals are
changing the order of commits, moving only part of a branch, rewriting
commits, etc.)

For more information, please see the full articles:

* A truce in the merge vs. rebase war? [1]
* Upstream rebase Just Works™ if history is retained [2]
* Rebase with history -- implementation ideas [3]

I'd appreciate feedback!

Michael

[1]
http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html
[2]
http://softwareswirl.blogspot.com/2009/08/upstream-rebase-just-works-if-history.html
[3]
http://softwareswirl.blogspot.com/2009/08/rebase-with-history-implementation.html