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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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

1. https://lore.kernel.org/git/221108.864jv9sc9r.gmgdl@evledraar.gmail.com/