On 09/11/2022 16:05, Ævar Arnfjörð Bjarmason wrote:
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).
It is worth noting that the leak that is fixed was unbounded and grew
with each commit whereas the new one is a fixed size and is only a
"leak" because we don't clean up properly when exiting.
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().
Yes, that was the main aim really
Best Wishes
Phillip
1. https://lore.kernel.org/git/221108.864jv9sc9r.gmgdl@xxxxxxxxxxxxxxxxxxx/
