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