Re: Rebase performance
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Feb 25, 2016, 17:30 UTC
- Message-ID
- <vpq37sg4s0l.fsf@anie.imag.fr>
- In-Reply-To
- <CACBZZX7rVAdzfCm=0FdrCXSx8a2=a8n7pjq1ZSW-V3fzmaSGWw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 9 quoted lines
> 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.
-- Matthieu Moy http://www-verimag.imag.fr/~moy/