Re: [PATCH 11/14] revert: Introduce a layer of indirection over pick_commits

Hi,

Jonathan Nieder writes:

Ramkumar Ramachandra wrote:

quoted

Jonathan Nieder writes:

quoted

In that case, I'd be mildly tempted to call it something crazy like
start_or_continue_replay()

[...]

quoted

Why? Is introducing new terminology so bad?  Should I explain what I
mean by "continuation" in the commit message/ a comment?

If "process_continuation" means "parse .git/sequencer state, which we
are pretending is a serialized continuation object, and either (a)
call it, (b) throw it away, or (c) modify it and then call it", then
yes, how do you expect anyone to know what you are talking about?

Less importantly, starting a cherry-pick (which is what pick_commits()
already does) doesn't seem to fit in that picture.

A simpler jargon-filled description of this model is checkpoint/
restart.  But it is an incomplete analogy and still not a great name.
With a goal of making future writers' lives happier and more
productive in mind, I do not think it is often worth confusing them by
choosing a clever presentation of ideas instead of a clear one.

Thanks for the elaborate explanation; I can see what's wrong with it
now.  However, I "start_or_continue_or_stop_or_[insert more options
here]_replay" isn't a good name.  I want something future-proof,
because I intend to extend this with more nifty helpers like "skip
one".  Your earlier "pick_revisions" suggestion doesn't sound like a
bad alternative now -- let me know if you have any other suggestions.

Thanks.

-- Ram