Re: [PATCH v3 0/3] sequencer: leave auto maintenance to the end of a sequence

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 8, 2026, 15:53 UTC
Message-ID: <xmqqse3jyc2m.fsf@gitster.g>
In-Reply-To: <pull.2217.v3.git.1788863286.gitgitgadget@gmail.com>

"Thomas Bachem via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 16 quoted lines

> Changes since v2:
>
>  * Auto maintenance now runs from builtin/rebase.c and builtin/revert.c,
>    once the command is done, instead of from three places inside the
>    sequencer. That follows the apply backend, where "git am" leaves it to
>    rebase.c (Patrick, Phillip).
>  * gc.auto=0 dropped, maintenance.auto=false is enough (Patrick).
>  * config_parameters is a char * built once with strbuf_detach() (Junio).
>  * Patch 3 extends the tests of patch 2 instead of adding its own. They also
>    assert that nothing runs before a stop, and cover a single pick with
>    --edit and a sequence ending in --skip (Phillip).
>  * Commit messages rewritten: what GIT_CONFIG_PARAMETERS is and looks like
>    (Patrick), what patch 2 changes for the user and why the call moved
>    (Patrick, Phillip), and the comment on the helper (Phillip).
>
> Based on master. Independent of the rerere lock fix in [1].

Will queue.

By the way, is it just me or are proposed log messages getting longer and longer with more irrelevant detaild these days?

If it is not just my imagination, this trend must stop.

Throw "Say the same thing in 1/N of the words used." followed by these proposed log messages to your near-by LLM, see if the output still makes sense, and adjust the value of N.

For example, I got the following from [3/3] with N==3 and I think that is far easier to understand than the original.

    Sequencer-spawned commands like 'commit' and 'merge' run
    background auto maintenance, which interferes with ongoing
    operations (e.g.  'rerere gc' holding MERGE_RR.lock or repacks
    deleting active packs).

    Pass maintenance.auto=false via GIT_CONFIG_PARAMETERS to all
    spawned commands.  Building this value after user settings
    ensures it wins and propagates to child processes.

    Auto maintenance now runs exactly once when the sequence
    completes.  Commands run manually by the user while stopped are
    unaffected and continue to run auto maintenance normally.

Thanks.