From: "Thomas Bachem via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: "D. Ben Knoble" <ben.knoble@gmail.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>,
Junio C Hamano <gitster@pobox.com>,
Patrick Steinhardt <ps@pks.im>,
Thomas Bachem <mail@thomasbachem.com>,
Thomas Bachem <mail@thomasbachem.com>
Subject: [PATCH v2] t5520: don't expire reflogs where it matters
Date: Tue, 29 Sep 2026 17:08:10 +0000 [thread overview]
Message-ID: <pull.2243.v2.git.1790701691022.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.2243.git.1790606282769.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 autostash tests in this script run eight such
merges.
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.
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.
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 v1: only the commit message, rewritten along the points
Phillip raised on Ben's copy of this patch:
https://lore.kernel.org/git/3547f4aa-649a-4f46-868c-0e50dfa69466@gmail.com/
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2243
Range-diff vs v1:
1: 1d8d6ed7f1 ! 1: 6699f3782e t5520: don't expire reflogs where it matters
@@ Metadata
## Commit message ##
t5520: don't expire reflogs where it matters
- 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.
+ "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 autostash tests in this script run eight such
+ merges.
- 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.
+ 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.
- 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.
+ 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.
+
+ 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>
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
next prev parent reply other threads:[~2026-09-29 17:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 14:38 [PATCH] t5520: don't expire reflogs where it matters Thomas Bachem via GitGitGadget
2026-09-28 20:45 ` Ben Knoble
2026-09-29 11:48 ` D. Ben Knoble
2026-09-29 15:59 ` Junio C Hamano
2026-09-29 15:02 ` Junio C Hamano
2026-09-29 15:29 ` D. Ben Knoble
2026-09-30 0:44 ` Junio C Hamano
2026-09-29 17:08 ` Thomas Bachem via GitGitGadget [this message]
2026-09-30 15:49 ` [PATCH v2] " Phillip Wood
2026-10-01 8:07 ` Thomas Bachem
2026-10-01 8:24 ` [PATCH v3] " Thomas Bachem via GitGitGadget
2026-10-01 15:48 ` Phillip Wood
2026-10-02 9:23 ` Thomas Bachem
2026-10-02 15:04 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pull.2243.v2.git.1790701691022.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mail@thomasbachem.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox