Re: [PATCH 06/17] revert: Eliminate global "commit" variable

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 13, 2011, 07:10 UTC
Message-ID: <20110713071029.GA31285@elie>
In-Reply-To: <CALkWK0k3muAi_h7GRqgJ9vY8SwHK40-AwMdjA=uCDO8Ng4utCA@mail.gmail.com>

Ramkumar Ramachandra wrote:

Show 20 quoted lines

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