Re: [PATCH] rebase -i: stop setting GIT_CHERRY_PICK_HELP

From: phillip.wood123@gmail.com <phillip.wood123@gmail.com>
Date: Feb 28, 2024, 14:45 UTC
Message-ID: <a11e3e0a-23a7-422f-9f3b-ab673860f1f8@gmail.com>
In-Reply-To: <xmqqil29sqfp.fsf@gitster.g>

On 27/02/2024 18:38, Junio C Hamano wrote:

Show 8 quoted lines

> "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> Note that we retain the changes in e4301f73fff (sequencer: unset
>> GIT_CHERRY_PICK_HELP for 'exec' commands, 2024-02-02) just in case
>> GIT_CHERRY_PICK_HELP is set in the environment when "git rebase" is
>> run.
> 
> Is this comment about this part of the code?

No, it is about

         strvec_push(&cmd.env, "GIT_CHERRY_PICK_HELP");

in do_exec() which clears GIT_CHERRY_PICK_HELP in the child environment when running an exec command so that "exec git cherry-pick ..." retains the correct author information.

Show 9 quoted lines

>> +	const char *msg;
>> +
>> +	if (is_rebase_i(opts))
>> +		msg = rebase_resolvemsg;
>> +	else
>> +		msg = getenv("GIT_CHERRY_PICK_HELP");
> 
> Testing is_rebase_i() first means we ignore the environment
> unconditionally and use our own message always in "rebase -i", no?

Yes, this matches the existing behavior in builtin/rebase.c where we call

	setenv("GIT_CHERRY_PICK_HELP", resolvemsg, 1);

to set GIT_CHERRY_PICK_HELP even if it is already set in the environment.

> Not that I think we should honor the environment variable and let it
> override our message.  I just found the description a bit confusing.

I should have been clearer what that it was talking about - i.e. it is still worth clearing GIT_CHERRY_PICK_HELP in the environment when running exec commands.

Best Wishes

Phillip

Show 15 quoted lines

>> diff --git a/sequencer.h b/sequencer.h
>> index dcef7bb99c0..437eabd38af 100644
>> --- a/sequencer.h
>> +++ b/sequencer.h
>> @@ -14,6 +14,8 @@ const char *rebase_path_todo(void);
>>   const char *rebase_path_todo_backup(void);
>>   const char *rebase_path_dropped(void);
>>   
>> +extern const char *rebase_resolvemsg;
> 
> This is more library-ish part of the system than a random file in
> the builtin/ directory.  This place as the final location for the
> string makes sense to me.
> 
> Thanks.