t5520: don't expire reflogs where it matters
PATCH 1/1 t5520: don't expire reflogs where it matters
From: Thomas Bachem <[email protected]>
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.
---
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/[email protected]/
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(+)
t/t5520-pull.sh +6 -0
@@ -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
Signature · 1 line
gitgitgadget
Quoted 34 lines · Thomas Bachem via GitGitGadget
From: Thomas Bachem <[email protected]>
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 <[email protected]>Helped-by D. Ben Knoble <[email protected]>Helped-by Phillip Wood <[email protected]>Assisted-by Claude Fable 5.1Signed-off-by Thomas Bachem <[email protected]>
Quoted 6 lines
---
t5520: don't expire reflogs where it mattersThe 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/[email protected]/
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.
Quoted 28 lines
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(+)t/t5520-pull.sh +0
-0@@ -35,6 +35,12 @@ test_pull_autostash_fail () { }
test_expect_successsetup 't/t5520-pull.sh +6
-0+ # 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 originalbase-commit:
34f06850c16c7f7ac822b1adc71354f11b0f2ca3--
gitgitgadget
Quoted 38 lines · Ben Knoble
Quoted 38 lines · Thomas Bachem via GitGitGadget
From: Thomas Bachem <[email protected]>
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 <[email protected]>Helped-by D. Ben Knoble <[email protected]>Helped-by Phillip Wood <[email protected]>Assisted-by Claude Fable 5.1Signed-off-by Thomas Bachem <[email protected]>---
t5520: don't expire reflogs where it matters
Quoted 5 lines
Quoted 3 lines
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/[email protected]/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.
I've confirmed this changes fixes the test interaction between our two topics.
Quoted 9 lines · D. Ben Knoble
Quoted 7 lines
Quoted 5 lines
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/[email protected]/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.
I've confirmed this changes fixes the test interaction between our two topics.
Wonderful. Thanks for a prompt confirmation.
Quoted 7 lines · Ben Knoble
Quoted 5 lines
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/[email protected]/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.
Either would work for me, but I created a synthetic base that includes this patch and queued your last iteration on top of it, before merging the result to 'seen' .
When you reroll, I'd reuse this synthetic base 4d7270214a (Merge branch 'tb/t5520-reflog-expire' into dk/stash-apply-index-incore, 2026-09-28)
Thanks.
Quoted 28 lines
Quoted 28 lines
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(+)t/t5520-pull.sh +0
-0@@ -35,6 +35,12 @@ test_pull_autostash_fail () { }
test_expect_successsetup 't/t5520-pull.sh +6
-0+ # 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 originalbase-commit:
34f06850c16c7f7ac822b1adc71354f11b0f2ca3--
gitgitgadget
Quoted 17 lines · Junio C Hamano
Quoted 9 lines · Ben Knoble
Quoted 5 lines
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/[email protected]/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.
Either would work for me, but I created a synthetic base that includes this patch and queued your last iteration on top of it, before merging the result to 'seen' .
Quoted 5 lines
When you reroll, I'd reuse this synthetic base
4d7270214a(Merge branch 'tb/t5520-reflog-expire' into dk/stash-apply-index-incore, 2026-09-28)Thanks.
Noted, will account for this in any further iterations.
Signature · 1 line
D. Ben Knoble
Quoted 7 lines · Junio C Hamano
Either would work for me, but I created a synthetic base that includes this patch and queued your last iteration on top of it, before merging the result to 'seen' .
When you reroll, I'd reuse this synthetic base
4d7270214a(Merge branch 'tb/t5520-reflog-expire' into dk/stash-apply-index-incore, 2026-09-28)
As Thomas updated the patch, I also had to update the synthetic base. It is now 59d1ce1b6e (Merge branch 'tb/t5520-reflog-expire' into dk/stash-apply-index-incore, 2026-09-29).
PATCH v2 1/1 t5520: don't expire reflogs where it matters
In reply to Thomas Bachem via GitGitGadgetFrom: Thomas Bachem <[email protected]>
"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.
---
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/[email protected]/
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/[email protected]/
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.
t/t5520-pull.sh | 6 ++++++ 1 file changed, 6 insertions(+)
t/t5520-pull.sh +6 -0
@@ -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
Signature · 1 line
gitgitgadget
Hi Thomas
Thanks for rewording this, it is much better now, but the comment about autostash at the end of the first paragraph is incorrect I think. As I think we need to fix that I've left a couple of other suggestions as well.
Quoted 7 lines · Thomas Bachem via GitGitGadget
From: Thomas Bachem <[email protected]>
"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.
Up to here it all makes sense
The autostash tests in this script run eight such merges.
This doesn't make sense to me. The tests that use "--autostash" will clear any changes from the index and worktree and so will never need to stash anything while trying different merge strategies which means those tests do not run "git stash apply --index".
Quoted 7 lines
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.
The second half of this sentence is true, but I'm not sure it is very relevant, all that really matters is that we're triggering "git reflog expire" at a different point in the test run which is already explained by the first half.
Quoted 1 line
With both, the expiry comes at the end of the "git pull --rebase" in
"With both" sounds a bit strange to me. Maybe
This means that unfortunately the reflogs are expired at the end of "git pull --rebase" in ...
Quoted 6 lines
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.
Good explanation
Quoted 3 lines
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.
Also good
Thanks
Phillip
Quoted 100 lines
Reported-by Junio C Hamano <[email protected]>Helped-by D. Ben Knoble <[email protected]>Helped-by Phillip Wood <[email protected]>Assisted-by Claude Fable 5.1Signed-off-by Thomas Bachem <[email protected]>---
t5520: don't expire reflogs where it mattersThe 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/[email protected]/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/[email protected]/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/2243Range-diff vs v1:
1:
1d8d6ed7f1! 1:6699f3782et5520: 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 aftertest_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, asea7d894f44(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 <[email protected]>Helped-by D. Ben Knoble <[email protected]>t/t5520-pull.sh | 6 ++++++ 1 file changed, 6 insertions(+)t/t5520-pull.sh +6
-0@@ -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 originalbase-commit:
34f06850c16c7f7ac822b1adc71354f11b0f2ca3
Hi Phillip,
Quoted 4 lines · Phillip Wood
This doesn't make sense to me. The tests that use "--autostash" will clear any changes from the index and worktree and so will never need to stash anything while trying different merge strategies which means those tests do not run "git stash apply --index".
You're right. On Monday I wrote that the merges don't come from the autostash tests [1], and in v2 that they do. Neither was exact.
They come from the tests that pull with autostash disabled. test_pull_autostash_fail stages a new file and expects the pull to fail, and eight of its calls merge rather than rebase, with "--no-autostash" or with pull.autostash set to false. The staged file is still there when "git merge" starts, so merge stashes it itself and restores it with "git stash apply --index" when the strategy does not handle the merge. The tests that do autostash never get there, as you say.
I'll say it like this in v3: "The tests that pull with autostash disabled run eight such merges, each with a new file staged."
Quoted 4 lines
The second half of this sentence is true, but I'm not sure it is very relevant, all that really matters is that we're triggering "git reflog expire" at a different point in the test run which is already explained by the first half.
I'll drop it.
Quoted 4 lines
"With both" sounds a bit strange to me. Maybe
This means that unfortunately the reflogs are expired at the end of "git pull --rebase" in ...
I'll take that.
Thanks,
Thomas
[1] <CAA0xjtpzaWH10pHOQ5j-5Hp1yHEKTDFbsicG6E4w=5nxb_irWw@mail.gmail.com>
PATCH v3 1/1 t5520: don't expire reflogs where it matters
In reply to Thomas Bachem via GitGitGadgetFrom: Thomas Bachem <[email protected]>
"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.
---
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/[email protected]/
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/[email protected]/
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(+)
t/t5520-pull.sh +6 -0
@@ -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
Signature · 1 line
gitgitgadget
Hi Thomas
This looks good. Thanks for the patch and also your help finding where the difference in reflog entry count was coming from - before your mail, I did not realize that "git merge" stashed changes without "--autostash".
Phillip
Quoted 111 lines · Thomas Bachem via GitGitGadget
From: Thomas Bachem <[email protected]>
"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 <[email protected]>Helped-by D. Ben Knoble <[email protected]>Helped-by Phillip Wood <[email protected]>Assisted-by Claude Fable 5.1Signed-off-by Thomas Bachem <[email protected]>---
t5520: don't expire reflogs where it mattersThe 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/[email protected]/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/[email protected]/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/2243Range-diff vs v2:
1:
6699f3782e! 1:be6c3f21c5t5520: 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(+)t/t5520-pull.sh +6
-0@@ -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 originalbase-commit:
34f06850c16c7f7ac822b1adc71354f11b0f2ca3
Hi Junio,
On 02/10/2026 00:48, Junio C Hamano wrote in What's cooking [1]:
Quoted 4 lines
The t5520 test script has been updated to disable reflog expiration. This prevents test flakiness caused by auto-maintenance running geometric repack which would otherwise immediately expire the test's reflogs due to them carrying hardcoded timestamps from 2005.
It's the reflog-expire task of auto maintenance that expires the reflogs, not the geometric repack.
Thanks,
Thomas
[1] <[email protected]>
Quoted 10 lines · Thomas Bachem
Hi Junio,
On 02/10/2026 00:48, Junio C Hamano wrote in What's cooking [1]:
Quoted 4 lines
The t5520 test script has been updated to disable reflog expiration. This prevents test flakiness caused by auto-maintenance running geometric repack which would otherwise immediately expire the test's reflogs due to them carrying hardcoded timestamps from 2005.
It's the reflog-expire task of auto maintenance that expires the reflogs, not the geometric repack.
Indeed. Thanks.