On Mon, Jun 27, 2011 at 11:36 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Thanks for a re-roll. > > I notice that this does not address the "side branch" issue raised during > the original discussion. I do agree with Michael > > http://thread.gmane.org/gmane.comp.version-control.git/135601/focus=135617 > > that having some commits on these part$N side branches is far more common > use case that would benefit from a "rewrite together" feature like this, > than moving part$N side branches that just mark points in the topic > without doing anything on their own and makes me doubt if doing only the > parts that can sanely done within the limitation of the current rebase-i > implementation like this series does adds much value to the system [*1*]. I would also like to support that use case. In my personal experience, the case where the part$N are ancestors of the topic has actually been the more common case; typically it's that part1 is some topic, and then part2 is a further topic that depends on the changes in part1, so naturally it goes directly on top of it. So I'd be pleased to get the functionality of the present series in, even before supporting the more general case. I agree with your footnote -- the more general case will require a more powerful sequencer to support properly. And now I see that Ramkumar Ramachandra is making progress on such a thing right now! That's great news -- this is a project that has been attempted at least four times, by five people (including me), in the last three years. I hope to see this round make it in -- I was actually thinking about returning to the problem after seeing this series through, but I would be glad to see Ram beat me to it. When the more powerful sequencer comes along, it may be necessary to rewrite some of this code in C (IIUC how the new sequencer will work), but that shouldn't be hard, and is probably easier starting from a shell version than from scratch. Other than that, this code should go in smoothly as the main ingredient, other than the sequencer itself, needed for the general "rewrite side branches" feature. With that and because this series is independently useful, my suggestion would be to merge it when it's ready in itself, without waiting for the sequencer. > It would be nice to have a clear definition of what _should_ happen in > this case, and a test that makes sure that that is the behaviour we get. > > Starting from this topology > > 1 2 topic > A---X---Y---Z---W > \ > B > > where the change going from A to B is an equilvalent to the change going > from Y to Z, a rebase of A..W would reproduce this topology: > > > 1 2 topic > A---X---Y---Z---W > \ > B---X'--Y'--W' > 1' topic' > > What should heppen to ref2? Should it be deleted? Should it point at Y'? I would have it point at Y'. That's what would happen if we just said "git rebase B ref2" (or threw in --rewrite-heads to pull along ref1), and I think it makes the most sense to be consistent. This consistency also means we can think of the reset that rebase performs when it finishes as equivalent to an implicit "ref refs/heads/topic" command at the end of the TODO file, which I wouldn't point out in explaining to a beginner but I think is a nice property for "ref" to have. I'll add a test for this scenario. Greg -- 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