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

["Thomas Bachem via GitGitGadget" <gitgitgadget@gmail.com>]

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
-- 
gitgitgadget