Björn Steinbrink wrote: > On 2009.08.14 00:39:48 +0200, Michael Haggerty wrote: >> Björn Steinbrink wrote: >>> On 2009.08.13 14:46:07 +0200, Michael Haggerty wrote: >>> And even for just continously forward porting a series of commits, a >>> common case might be that upstream applied some patches, but not all. >>> Can you deal with that? [A discussion of various unsatisfactory approaches omitted...] > But that's obviously total crap. So I think we agree that it is not possible to retain history for a case like this (which is essentially a general cherry-pick). > [...] > Doing a plain "git rebase subsystem topic" would of course also try to > rebase the "o" commits, so that problematic. Instead, you do: > > git rebase --onto subsystem O topic > > That turns O..topic (the * commits) into patches, and applies them on > top of O'. So the "o" commits aren't to be rebased. > > And that's exactly what your rebase-with-history would do as well. Just > that O is naturally a common ancestor of subsystem and topic, and so > just using "git rebase-w-h subsystem topic" would be enough. Conflicts > etc. should be 100% the same. > > If you know that your upstream is going to rebase/rewrite history, you > can tag (or otherwise mark) the current branching point of your branch, > so you can easily specify it for the --onto rebase. IOW: This is > primarily a social problem (tell your downstream that you rebase this or > that branch), but having built-in support to store the branching point > for rebasing _might_ be worth a thought. Recording branch points manually, coordinating merges via email -- OMG you are giving me flashbacks of CVS ;-) *Of course* you can get around all of these problems if you put the burden of bookkeeping on the user. The whole point of rebase-with-history is to have the VCS handle it automatically! >> and merging in a topic branch makes it more difficult to create an >> easily-reviewable patch series. rebase-with-history has neither of >> these problems. > > Sure, merging is a no-go if you submit patches by email (or other, > similar means). But you compared that to an "enhanced" rebase approach, > instead of comparing your rebase approach to the currently available > one. In [1] I compared rebase-with-history with both of the currently-available options (rebase and merge). Rebase and merge can each deal with some of the issues that come up, but each one falls flat on others. I believe that rebase-with-history has the advantages of both. The example in [2] was taken straight from the git-rebase man page [3]; I did not want to claim that current practice would use merging in this situation, but rather just to show that rebase-with-history removes the pain from this well-known example. I think we are mostly in agreement. Rebase-with-history is obviously not an earth-shattering revolution in DVCS technology, but my hope is that it could unobtrusively assist with a few minor pain points. 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://www.kernel.org/pub/software/scm/git/docs/git-rebase.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