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

Johannes Schindelin [off-list ref] writes:

quoted

quoted

...  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.

Yes, we are on the same page.  What Elijah proposed as "another
backend" would unfortunately be different, and needs to be adjusted
with such an "only when needed" tweak.  The check hopefully needs to
be done only once (e.g. do we have this hook enabled?  do we have
that hook enabled? do we have a commit with this trait in the range
being worked on? etc. etc.) upfront and for certain workflows may
not require any persistence.

And until that happens, "annoying deprecation notices" will never be
a viable step to take.