Ramkumar Ramachandra wrote:
> Right. How about this?
>
> revert: Eliminate global "commit" variable
>
> Functions which act on commits currently rely on a file-scope static
> variable to be set before they're called. Consequently, the API and
> corresponding callsites are ugly and unclear. Remove this variable
> and change their API to accept the commit to act on as additional
> argument so that the callsites change from looking like
>
> commit = prepare_a_commit();
> act_on_commit();
>
> to looking like
>
> commit = prepare_a_commit();
> act_on_commit(commit);
>
> This change is also in line with our long-term goal of exposing some
> of these functions through a public API.
Sounds fine to me. I could nitpick by saying that "Functions which
act on commits" is a little vague (I think the actual story is
something like "The global 'commit' variable used to represent one of
the arguments passed to 'git cherry-pick' or 'git revert' and thus was
static along with the options. When cherry-pick learned to replay
multiple commits in sequence, that wasn't changed, resulting in a
somewhat unnatural calling sequence that uses a global to pass in a
parameters:
for each commit c {
commit = c;
res = do_pick_commit();
if (res)
return res;
}
Teach do_pick_commit and the functions it calls to accept the commit
to act on as an argument, like we always should have. Part of a
campaign to clean up cherry-pick/revert's internal APIs before
exposing them.")
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html