Michael J Gruber wrote: > BTW: How does the sequencer based rebase do in this case, This was the first thing I checked :-) I had to rework the rebase -i -p code for sequencer a bit, but this case was not something I had thought about (although it may not be too seldom), so I'm glad it comes up now. The result is that it eats the commits a3 and a4. (But at least it does the same with and without --onto master.) :-) I think it's not too hard to fix. > and what's the general status? I'm currently highly motivated to get it done soon and I hope that it gets into pu or next before the end of January. Depending on how productive I am over the weekend and depending on how many further bugs (often hidden in such special cases) I find, it could be sent to the list next week. > If it's about to be integrated we can do without the > present script... I think it will take some time and some discussions on the list until it will be integrated. I remember, for example, Dscho, who has, since it had first come up, always been opposed to the mark-reset / mark-reset-merge scheme (in rebase -i -p, at least). Other users said "Wow, this is much more flexible." ... and this is perhaps only one thing that can lead to some bigger discussion. Regards, Stephan -- Stephan Beyer <s-beyer@xxxxxxx>, PGP 0x6EDDD207FCC5040F -- 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
