Re: [PATCH v2 0/2] rebase: stop setting GIT_REFLOG_ACTION

> 
> On Wed, Nov 09 2022, Phillip Wood via GitGitGadget wrote:
> 
>> This is a follow up to pw/rebase-reflog-fixes that moves away from using
>> GIT_REFLOG_ACTION internally.
>>
>> Thanks to Taylor & Ævar for their comments on V1. I've updated the commit
>> message of patch 1 as suggested by Taylor, the code is unchanged.
>>
>> Phillip Wood (2):
>>    sequencer: stop exporting GIT_REFLOG_ACTION
>>    rebase: stop exporting GIT_REFLOG_ACTION
>>
>>   builtin/rebase.c | 27 +++++++++++++++------------
>>   sequencer.c      | 45 +++++++++++++++++++++++++--------------------
>>   sequencer.h      |  6 ++++++
>>   3 files changed, 46 insertions(+), 32 deletions(-)
>>
>>
>> base-commit: 3b08839926fcc7cc48cf4c759737c1a71af430c1
>> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1405%2Fphillipwood%2Fmore-rebase-reflog-fixes-v2
>> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1405/phillipwood/more-rebase-reflog-fixes-v2
>> Pull-Request: https://github.com/gitgitgadget/git/pull/1405
>>
>> Range-diff vs v1:
>>
>>   1:  e9c3f5ac5c6 ! 1:  655b4e89f59 sequencer: stop exporting GIT_REFLOG_ACTION
>>       @@ Commit message
>>            pass the reflog action around in a variable and use it to set
>>            GIT_REFLOG_ACTION in the child environment when running "git commit".
>>        
>>       +    Within the sequencer GIT_REFLOG_ACTION is no longer set and is only read
>>       +    by sequencer_reflog_action(). It is still set by rebase before calling
>>       +    the sequencer, that will be addressed in the next commit. cherry-pick
>>       +    and revert are unaffected as they do not set GIT_REFLOG_ACTION before
>>       +    calling the sequencer.
>>       +
>>            Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
>>        
>>         ## sequencer.c ##
>>   2:  d3747bcc8d1 = 2:  31df037eafe rebase: stop exporting GIT_REFLOG_ACTION
> 
> Thanks, FWIW I'm happy to give this my "Reviewed-by", per [1] I've
> looked this over carefully.
> 
> The tl;dr of that is that this fixes a leak, and adds another one, but
> the root cause of the added one is that you're using an existing
> destructor that we sometimes don't call, which we can just address as a
> follow-up generic issue (I've got patches to fix it).

> But for now this is a good step forward, and fixes the leak that's
> "unique" t this codepath.
> 
> And of course, just makes managing the "reflog" variable nicer in
> general, as we're no longer talking to ourselves within the same process
> with setenv()/getenv().