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@xxxxxxxxxxxxx> > > ## 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@xxxxxxxxxxxxxxxxxxx/
