Hi, On Thu, 26 Feb 2009, Sverre Rabbelier wrote: > On Thu, Feb 26, 2009 at 15:59, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > This code is supposed to do exactly what you want: > > Hmmm, I can't say I understand it 100%, but what I can see from > reading the code and looking at the output of 'rebase -i -v' is that > it does a 'git reset --hard' on each commit if it was already applied, > instead of figuring out beforehand what to reset to? If that is the > case, it might still take a long time to do the rebase if it takes > long to do the 'reset --hard' between the patches (say, if a big > change is made). Right. I am of two minds here: On one hand, I could imagine that it is just a question of skipping those 'pick' commands that do not contribute anything. That would be a pretty simple function that would be called at the very beginning. On the other hand, this very simple strategy would fail pretty quickly (and badly) with -i -p. And that is the stuff I am mostly spending my Git time budget on these days. Having said that, I think yours might be such a common case that it is worth optimizing for. Ciao, Dscho -- 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
