Re: unifying sequencer's options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages

>
> On Fri, 2 Apr 2021, Junio C Hamano wrote:
>
> > Elijah Newren <newren@gmail.com> 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.