Re: Rebase performance

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Hi Matthieu,

On Thu, 25 Feb 2016, Matthieu Moy wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > At the risk of derailing this thread, a thing that would make rebase
> > even faster I think would be to change it so that instead of applying
> > a patch at a time to the working tree the whole operation takes place
> > on temporary trees & commits and then we'll eventually move the branch
> > pointer to that once it's finished.
> >
> > I.e. there's no reason for why a sequence of 1000 patches where a
> > FOO.txt is changed from "hi1", "hi2", "hi3", ... would be noticeably
> > slower than applying the same changes with git-fast-import.
> 
> Also, not touching the worktree during rebase would have the advantage
> that if the final result doesn't change a file, we wouldn't need to
> touch this file at all, hence the next "make" (or whatever
> timestamp-using build system the user runs) would consider this file
> unchanged.

We still have to write all blobs. So I would still expect this to be I/O
bound.

Ciao,
Dscho