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

> From: Thomas Bachem <mail@thomasbachem.com>
> 
> "git merge" saves any uncommitted changes with "git stash" before it
> tries a merge strategy. When the strategy does not handle the merge,
> it restores them with "git stash apply --index". If some of the
> changes are staged, that runs "git reset", which writes an entry to
> the reflog of HEAD. The tests that pull with autostash disabled run
> eight such merges, each with a new file staged.
> 
> An upcoming change makes "git stash apply --index" merge the index
> in-core, so it no longer runs "git reset" and those entries go away.
> Another makes the default "merge" backend of "git rebase" run auto
> maintenance when it finishes. Together, they change when auto
> maintenance expires the reflogs.
> 
> This means that unfortunately the reflogs are expired at the end of
> "git pull --rebase" in the "--rebase with rebased upstream" test. The
> "git pull --rebase -f" in the next test looks for the fork point in
> the reflog of refs/remotes/me/copy, but as the test suite dates every
> reflog entry to 2005, the expiry has emptied that reflog. Pull then
> finds no fork point, so the rebase also replays copy-orig, the commit
> "copy" was rewound from, and it conflicts.
> 
> Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't
> expire reflogs where it matters, 2026-02-24) did for the rebase tests,
> so that the test no longer depends on where the expiry falls.
> 
> 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/
>      
>      Changes since v2: only the commit message. I had the eight merges in the
>      wrong tests: they come from the pulls with autostash disabled, where
>      "git merge" stashes and restores the staged file itself. I also dropped
>      the clause about the hundred entries and took Phillip's opening for the
>      third paragraph, all from his review:
>      https://lore.kernel.org/git/8b81c508-ac67-498d-b78f-a4b5dab8c198@gmail.com/
> 
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v3
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v3
> Pull-Request: https://github.com/gitgitgadget/git/pull/2243
> 
> Range-diff vs v2:
> 
>   1:  6699f3782e ! 1:  be6c3f21c5 t5520: don't expire reflogs where it matters
>       @@ Commit message
>            tries a merge strategy. When the strategy does not handle the merge,
>            it restores them with "git stash apply --index". If some of the
>            changes are staged, that runs "git reset", which writes an entry to
>       -    the reflog of HEAD. The autostash tests in this script run eight such
>       -    merges.
>       +    the reflog of HEAD. The tests that pull with autostash disabled run
>       +    eight such merges, each with a new file staged.
>        
>            An upcoming change makes "git stash apply --index" merge the index
>            in-core, so it no longer runs "git reset" and those entries go away.
>            Another makes the default "merge" backend of "git rebase" run auto
>            maintenance when it finishes. Together, they change when auto
>       -    maintenance expires all reflogs, which it does once a hundred entries
>       -    in the reflog of HEAD are due to expire.
>       +    maintenance expires the reflogs.
>        
>       -    With both, the expiry comes at the end of the "git pull --rebase" in
>       -    the "--rebase with rebased upstream" test. The "git pull --rebase -f"
>       -    in the next test looks for the fork point in the reflog of
>       -    refs/remotes/me/copy, but as the test suite dates every reflog entry
>       -    to 2005, the expiry has emptied that reflog. Pull then finds no fork
>       -    point, so the rebase also replays copy-orig, the commit "copy" was
>       -    rewound from, and it conflicts.
>       +    This means that unfortunately the reflogs are expired at the end of
>       +    "git pull --rebase" in the "--rebase with rebased upstream" test. The
>       +    "git pull --rebase -f" in the next test looks for the fork point in
>       +    the reflog of refs/remotes/me/copy, but as the test suite dates every
>       +    reflog entry to 2005, the expiry has emptied that reflog. Pull then
>       +    finds no fork point, so the rebase also replays copy-orig, the commit
>       +    "copy" was rewound from, and it conflicts.
>        
>            Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't
>            expire reflogs where it matters, 2026-02-24) did for the rebase tests,
> 
> 
>   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