From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Wed, 06 Jul 2011 11:44:59 GMT
Subject: Re: [PATCH 11/14] revert: Introduce a layer of indirection over pick_commits
Message-ID: <CALkWK0mXQszjM57E==YCisUng8buyMmP6EGkcrncJOkNJhK35Q@mail.gmail.com>
In-Reply-To: <20110706113928.GO15682@elie>

Hi,

Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>> Jonathan Nieder writes:
>>> In that case, I'd be mildly tempted to call it something crazy like
>>> start_or_continue_replay()
> [...]
>> 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