Hi Matthieu, On Thu, 25 Feb 2016, Matthieu Moy wrote:
> Ævar Arnfjörð Bjarmason <ava...@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
