Re: [PATCH] t5520: don't expire reflogs where it matters

[Ben Knoble <ben.knoble@gmail.com>]

> Le 28 sept. 2026 à 10:38, Thomas Bachem via GitGitGadget <gitgitgadget@gmail.com> a écrit :
> 
> From: Thomas Bachem <mail@thomasbachem.com>
> 
> The "--rebase -f with rebased upstream" test computes its fork point
> from the reflog of refs/remotes/me/copy, and the entry it needs is
> the one that the fetch of the test before it wrote. Like every reflog
> entry the suite writes after test_tick, it is dated 2005, so the
> first "git reflog expire --all" after that fetch removes it. Pull
> then finds no fork point and rebases onto the merge head with the
> merge head as the upstream, and the rewound commits come back as a
> conflict.
> 
> Since 452b12c2e0 (builtin/maintenance: use "geometric" strategy by
> default, 2026-02-24) auto maintenance runs that expiry once the reflog
> of HEAD holds a hundred entries it would remove, the default of
> maintenance.reflog-expire.auto. Which run crosses the threshold
> depends on the entries and maintenance runs before it, so the script
> passed by chance: a stash topic that no longer runs "git reset" from
> "stash apply --index" and a rebase topic that runs auto maintenance
> at the end of "git rebase" together move the expiry between the two
> tests.
> 
> Pin the expiry as ea7d894f44 (t34xx: don't expire reflogs where it
> matters, 2026-02-24) did for the rebase tests. That covers a "git gc"
> as well, which expires reflogs on its own, where turning off the auto
> trigger of the reflog-expire task alone would not.
> 
> Reported-by: Junio C Hamano <gitster@pobox.com>
> Helped-by: D. Ben Knoble <ben.knoble@gmail.com>
> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> Assisted-by: Claude Fable 5.1
> Signed-off-by: Thomas Bachem <mail@thomasbachem.com>
> ---
>    t5520: don't expire reflogs where it matters
> 
>    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,
>    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:
>    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/

Junio, if it’s simpler for you this way: I’ll just pick this patch into my series rather than wait for it to appear in seen and recreate my topic on master + it.

> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/2243
> 
> t/t5520-pull.sh | 6 ++++++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> index 27f38ab3c8..bc818605a5 100755
> --- a/t/t5520-pull.sh
> +++ b/t/t5520-pull.sh
> @@ -35,6 +35,12 @@ test_pull_autostash_fail () {
> }
> 
> test_expect_success setup '
> +    # Commit dates are hardcoded to 2005, and the reflog entries will have
> +    # a matching timestamp. Maintenance may thus immediately expire
> +    # reflogs if it was running.
> +    git config set gc.reflogExpire never &&
> +    git config set gc.reflogExpireUnreachable never &&
> +
>    echo file >file &&
>    git add file &&
>    git commit -a -m original
> 
> base-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3
> --
> gitgitgadget