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

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

[Thomas Bachem via GitGitGadget]

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/

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

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

[Ben Knoble]

> 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

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

[D. Ben Knoble]

On Mon, Sep 28, 2026 at 4:45 PM Ben Knoble <ben.knoble@gmail.com> wrote:
>
>
> > 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.

I've confirmed this changes fixes the test interaction between our two topics.

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

[Junio C Hamano]

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

>> >    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.
>
> I've confirmed this changes fixes the test interaction between our two topics.

Wonderful.  Thanks for a prompt confirmation.

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

[Junio C Hamano]

Ben Knoble <ben.knoble@gmail.com> writes:

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

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.

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

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

[D. Ben Knoble]

On Tue, Sep 29, 2026 at 11:02 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Ben Knoble <ben.knoble@gmail.com> writes:
>
> >>    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.
>
> 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.

Noted, will account for this in any further iterations.

-- 
D. Ben Knoble

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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] t5520: don't expire reflogs where it matters

[Thomas Bachem via GitGitGadget]

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

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

[Phillip Wood]

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.

On 29/09/2026 18:08, Thomas Bachem via GitGitGadget wrote:
> 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. 

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".
> 
> 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.

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

> 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

> 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

> 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

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

[Thomas Bachem]

Hi Phillip,

On 30/09/2026 16:49, Phillip Wood wrote:
> 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."

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

> "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] t5520: don't expire reflogs where it matters

[Thomas Bachem via GitGitGadget]

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

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

[Phillip Wood]

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

On 01/10/2026 09:24, Thomas Bachem via GitGitGadget wrote:
> 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

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

[Thomas Bachem]

Hi Junio,

On 02/10/2026 00:48, Junio C Hamano wrote in What's cooking [1]:
> 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] <xmqqv77l2g2e.fsf@gitster.g>

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

[Junio C Hamano]

Thomas Bachem <mail@thomasbachem.com> writes:

> Hi Junio,
>
> On 02/10/2026 00:48, Junio C Hamano wrote in What's cooking [1]:
>> 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.