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

> 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

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

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

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

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

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

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

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

> 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

> 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

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