Re: [RFH] rebase -i optimization

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 27, 2009, 10:50 UTC
Message-ID: <alpine.DEB.1.00.0902271146460.6600@intel-tinevez-2-302>
In-Reply-To: <fabb9a1e0902260733k26e5c02i75a7866f9a67530b@mail.gmail.com>

Hi,

On Thu, 26 Feb 2009, Sverre Rabbelier wrote:

Show 11 quoted lines

> On Thu, Feb 26, 2009 at 15:59, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> 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