Hi, On Fri, 2 Apr 2021, Junio C Hamano wrote: > Elijah Newren <newren@xxxxxxxxx> writes: > > > Even if others now disagree with the above, I know I can get a huge > > speedup by changing sequencer to stop per-commit wasteful work (stop > > forking processes like "git commit", don't write control structures if > > the rebase hasn't ended or hit a conflict, don't update the working > > copy or index or reflog). It's enough of a speedup that if backward > > compatibility won't allow such a method to be used by default, I'd > > still make yet another backend that could be optionally used. And I'd > > have the default rebase and cherry-pick start printing annoying > > deprecation notices so that users become aware of a faster option. > > A faster and less powerful interface is good; I doubt deprecation > would work well. If a workflow depends on things like post-commit > hook, the affected users deserve some way to migrate to --exec or > whatever method to compensate the loss of functionality. I could imagine that there is opportunity to "persist on disk only when needed". For example, if no `pre-commit` hook is installed that needs to be run, there is no need to update the worktree nor HEAD until the rebase is done. And this type of `only write to disk when needed` functionality could probably be abstracted away so much as to make the rest of the code look elegant again. Ciao, Dscho
