{"thread":{"id":"66407","subject":"[PATCH] t5520: don't expire reflogs where it matters","startedAt":"2026-09-28T14:38:07Z","lastAt":"2026-10-02T15:04:20Z","messageCount":14,"participants":["Thomas Bachem via GitGitGadget","Ben Knoble","D. Ben Knoble","Junio C Hamano","Phillip Wood","Thomas Bachem"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"553481","messageId":"pull.2243.git.1790606282769.gitgitgadget@gmail.com","threadId":"66407","inReplyTo":null,"subject":"[PATCH] t5520: don't expire reflogs where it matters","fromName":"Thomas Bachem via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-28T14:38:02Z","receivedAt":"2026-09-28T14:38:07Z","isPatch":true,"body":"From: Thomas Bachem <mail@thomasbachem.com>\n\nThe \"--rebase -f with rebased upstream\" test computes its fork point\nfrom the reflog of refs/remotes/me/copy, and the entry it needs is\nthe one that the fetch of the test before it wrote. Like every reflog\nentry the suite writes after test_tick, it is dated 2005, so the\nfirst \"git reflog expire --all\" after that fetch removes it. Pull\nthen finds no fork point and rebases onto the merge head with the\nmerge head as the upstream, and the rewound commits come back as a\nconflict.\n\nSince 452b12c2e0 (builtin/maintenance: use \"geometric\" strategy by\ndefault, 2026-02-24) auto maintenance runs that expiry once the reflog\nof HEAD holds a hundred entries it would remove, the default of\nmaintenance.reflog-expire.auto. Which run crosses the threshold\ndepends on the entries and maintenance runs before it, so the script\npassed by chance: a stash topic that no longer runs \"git reset\" from\n\"stash apply --index\" and a rebase topic that runs auto maintenance\nat the end of \"git rebase\" together move the expiry between the two\ntests.\n\nPin the expiry as ea7d894f44 (t34xx: don't expire reflogs where it\nmatters, 2026-02-24) did for the rebase tests. That covers a \"git gc\"\nas well, which expires reflogs on its own, where turning off the auto\ntrigger of the reflog-expire task alone would not.\n\nReported-by: Junio C Hamano <gitster@pobox.com>\nHelped-by: D. Ben Knoble <ben.knoble@gmail.com>\nHelped-by: Phillip Wood <phillip.wood@dunelm.org.uk>\nAssisted-by: Claude Fable 5.1\nSigned-off-by: Thomas Bachem <mail@thomasbachem.com>\n---\n    t5520: don't expire reflogs where it matters\n    \n    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/2243\n\n t/t5520-pull.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 27f38ab3c8..bc818605a5 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -35,6 +35,12 @@ test_pull_autostash_fail () {\n }\n \n test_expect_success setup '\n+\t# Commit dates are hardcoded to 2005, and the reflog entries will have\n+\t# a matching timestamp. Maintenance may thus immediately expire\n+\t# reflogs if it was running.\n+\tgit config set gc.reflogExpire never &&\n+\tgit config set gc.reflogExpireUnreachable never &&\n+\n \techo file >file &&\n \tgit add file &&\n \tgit commit -a -m original\n\nbase-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3\n-- \ngitgitgadget\n"},{"id":"553523","messageId":"89E3CD2E-8366-4C5A-B3A4-8F44AC5F89DF@gmail.com","threadId":"66407","inReplyTo":"pull.2243.git.1790606282769.gitgitgadget@gmail.com","subject":"Re: [PATCH] t5520: don't expire reflogs where it matters","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-28T20:45:19Z","receivedAt":"2026-09-28T20:45:31Z","isPatch":true,"body":"\n> Le 28 sept. 2026 à 10:38, Thomas Bachem via GitGitGadget <gitgitgadget@gmail.com> a écrit :\n> \n> ﻿From: Thomas Bachem <mail@thomasbachem.com>\n> \n> The \"--rebase -f with rebased upstream\" test computes its fork point\n> from the reflog of refs/remotes/me/copy, and the entry it needs is\n> the one that the fetch of the test before it wrote. Like every reflog\n> entry the suite writes after test_tick, it is dated 2005, so the\n> first \"git reflog expire --all\" after that fetch removes it. Pull\n> then finds no fork point and rebases onto the merge head with the\n> merge head as the upstream, and the rewound commits come back as a\n> conflict.\n> \n> Since 452b12c2e0 (builtin/maintenance: use \"geometric\" strategy by\n> default, 2026-02-24) auto maintenance runs that expiry once the reflog\n> of HEAD holds a hundred entries it would remove, the default of\n> maintenance.reflog-expire.auto. Which run crosses the threshold\n> depends on the entries and maintenance runs before it, so the script\n> passed by chance: a stash topic that no longer runs \"git reset\" from\n> \"stash apply --index\" and a rebase topic that runs auto maintenance\n> at the end of \"git rebase\" together move the expiry between the two\n> tests.\n> \n> Pin the expiry as ea7d894f44 (t34xx: don't expire reflogs where it\n> matters, 2026-02-24) did for the rebase tests. That covers a \"git gc\"\n> as well, which expires reflogs on its own, where turning off the auto\n> trigger of the reflog-expire task alone would not.\n> \n> Reported-by: Junio C Hamano <gitster@pobox.com>\n> Helped-by: D. Ben Knoble <ben.knoble@gmail.com>\n> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>\n> Assisted-by: Claude Fable 5.1\n> Signed-off-by: Thomas Bachem <mail@thomasbachem.com>\n> ---\n>    t5520: don't expire reflogs where it matters\n> \n>    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n>    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n>    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n\nJunio, 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.\n\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/2243\n> \n> t/t5520-pull.sh | 6 ++++++\n> 1 file changed, 6 insertions(+)\n> \n> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\n> index 27f38ab3c8..bc818605a5 100755\n> --- a/t/t5520-pull.sh\n> +++ b/t/t5520-pull.sh\n> @@ -35,6 +35,12 @@ test_pull_autostash_fail () {\n> }\n> \n> test_expect_success setup '\n> +    # Commit dates are hardcoded to 2005, and the reflog entries will have\n> +    # a matching timestamp. Maintenance may thus immediately expire\n> +    # reflogs if it was running.\n> +    git config set gc.reflogExpire never &&\n> +    git config set gc.reflogExpireUnreachable never &&\n> +\n>    echo file >file &&\n>    git add file &&\n>    git commit -a -m original\n> \n> base-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3\n> --\n> gitgitgadget\n"},{"id":"553591","messageId":"CALnO6CDMTHw9EqvvD5_s7WhFVhukr936ddhuJwdOhdJGdwmrRA@mail.gmail.com","threadId":"66407","inReplyTo":"89E3CD2E-8366-4C5A-B3A4-8F44AC5F89DF@gmail.com","subject":"Re: [PATCH] t5520: don't expire reflogs where it matters","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-29T11:48:08Z","receivedAt":"2026-09-29T11:48:20Z","isPatch":true,"body":"On Mon, Sep 28, 2026 at 4:45 PM Ben Knoble <ben.knoble@gmail.com> wrote:\n>\n>\n> > Le 28 sept. 2026 à 10:38, Thomas Bachem via GitGitGadget <gitgitgadget@gmail.com> a écrit :\n> >\n> > ﻿From: Thomas Bachem <mail@thomasbachem.com>\n> >\n> > The \"--rebase -f with rebased upstream\" test computes its fork point\n> > from the reflog of refs/remotes/me/copy, and the entry it needs is\n> > the one that the fetch of the test before it wrote. Like every reflog\n> > entry the suite writes after test_tick, it is dated 2005, so the\n> > first \"git reflog expire --all\" after that fetch removes it. Pull\n> > then finds no fork point and rebases onto the merge head with the\n> > merge head as the upstream, and the rewound commits come back as a\n> > conflict.\n> >\n> > Since 452b12c2e0 (builtin/maintenance: use \"geometric\" strategy by\n> > default, 2026-02-24) auto maintenance runs that expiry once the reflog\n> > of HEAD holds a hundred entries it would remove, the default of\n> > maintenance.reflog-expire.auto. Which run crosses the threshold\n> > depends on the entries and maintenance runs before it, so the script\n> > passed by chance: a stash topic that no longer runs \"git reset\" from\n> > \"stash apply --index\" and a rebase topic that runs auto maintenance\n> > at the end of \"git rebase\" together move the expiry between the two\n> > tests.\n> >\n> > Pin the expiry as ea7d894f44 (t34xx: don't expire reflogs where it\n> > matters, 2026-02-24) did for the rebase tests. That covers a \"git gc\"\n> > as well, which expires reflogs on its own, where turning off the auto\n> > trigger of the reflog-expire task alone would not.\n> >\n> > Reported-by: Junio C Hamano <gitster@pobox.com>\n> > Helped-by: D. Ben Knoble <ben.knoble@gmail.com>\n> > Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>\n> > Assisted-by: Claude Fable 5.1\n> > Signed-off-by: Thomas Bachem <mail@thomasbachem.com>\n> > ---\n> >    t5520: don't expire reflogs where it matters\n> >\n> >    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n> >    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n> >    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n>\n> 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.\n\nI've confirmed this changes fixes the test interaction between our two topics.\n"},{"id":"553606","messageId":"xmqqzex0hzhf.fsf@gitster.g","threadId":"66407","inReplyTo":"89E3CD2E-8366-4C5A-B3A4-8F44AC5F89DF@gmail.com","subject":"Re: [PATCH] t5520: don't expire reflogs where it matters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-29T15:02:52Z","receivedAt":"2026-09-29T15:03:00Z","isPatch":true,"body":"Ben Knoble <ben.knoble@gmail.com> writes:\n\n>>    t5520: don't expire reflogs where it matters\n>> \n>>    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n>>    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n>>    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n>\n> 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.\n\nEither would work for me, but I created a synthetic base that\nincludes this patch and queued your last iteration on top of it,\nbefore merging the result to 'seen' .\n\nWhen you reroll, I'd reuse this synthetic base 4d7270214a (Merge\nbranch 'tb/t5520-reflog-expire' into dk/stash-apply-index-incore,\n2026-09-28)\n\nThanks.\n\n>> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v1\n>> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v1\n>> Pull-Request: https://github.com/gitgitgadget/git/pull/2243\n>> \n>> t/t5520-pull.sh | 6 ++++++\n>> 1 file changed, 6 insertions(+)\n>> \n>> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\n>> index 27f38ab3c8..bc818605a5 100755\n>> --- a/t/t5520-pull.sh\n>> +++ b/t/t5520-pull.sh\n>> @@ -35,6 +35,12 @@ test_pull_autostash_fail () {\n>> }\n>> \n>> test_expect_success setup '\n>> +    # Commit dates are hardcoded to 2005, and the reflog entries will have\n>> +    # a matching timestamp. Maintenance may thus immediately expire\n>> +    # reflogs if it was running.\n>> +    git config set gc.reflogExpire never &&\n>> +    git config set gc.reflogExpireUnreachable never &&\n>> +\n>>    echo file >file &&\n>>    git add file &&\n>>    git commit -a -m original\n>> \n>> base-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3\n>> --\n>> gitgitgadget\n"},{"id":"553608","messageId":"CALnO6CD9SPARnfFY3VUELN4FqmVrus2qPLg_6nPNLtFY95Nkaw@mail.gmail.com","threadId":"66407","inReplyTo":"xmqqzex0hzhf.fsf@gitster.g","subject":"Re: [PATCH] t5520: don't expire reflogs where it matters","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-29T15:29:29Z","receivedAt":"2026-09-29T15:29:41Z","isPatch":true,"body":"On Tue, Sep 29, 2026 at 11:02 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Ben Knoble <ben.knoble@gmail.com> writes:\n>\n> >>    t5520: don't expire reflogs where it matters\n> >>\n> >>    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n> >>    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n> >>    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n> >\n> > Junio, if it’s simpler for you this way: I’ll just pick this patch\n> > into my series rather than wait for it to appear in seen and\n> > recreate my topic on master + it.\n>\n> Either would work for me, but I created a synthetic base that\n> includes this patch and queued your last iteration on top of it,\n> before merging the result to 'seen' .\n>\n> When you reroll, I'd reuse this synthetic base 4d7270214a (Merge\n> branch 'tb/t5520-reflog-expire' into dk/stash-apply-index-incore,\n> 2026-09-28)\n>\n> Thanks.\n\nNoted, will account for this in any further iterations.\n\n-- \nD. Ben Knoble\n"},{"id":"553612","messageId":"xmqqse2shwvf.fsf@gitster.g","threadId":"66407","inReplyTo":"CALnO6CDMTHw9EqvvD5_s7WhFVhukr936ddhuJwdOhdJGdwmrRA@mail.gmail.com","subject":"Re: [PATCH] t5520: don't expire reflogs where it matters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-29T15:59:16Z","receivedAt":"2026-09-29T15:59:20Z","isPatch":true,"body":"\"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n\n>> >    t5520: don't expire reflogs where it matters\n>> >\n>> >    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n>> >    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n>> >    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n>>\n>> 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.\n>\n> I've confirmed this changes fixes the test interaction between our two topics.\n\nWonderful.  Thanks for a prompt confirmation.\n"},{"id":"553618","messageId":"pull.2243.v2.git.1790701691022.gitgitgadget@gmail.com","threadId":"66407","inReplyTo":"pull.2243.git.1790606282769.gitgitgadget@gmail.com","subject":"[PATCH v2] t5520: don't expire reflogs where it matters","fromName":"Thomas Bachem via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-29T17:08:10Z","receivedAt":"2026-09-29T17:08:14Z","isPatch":true,"body":"From: Thomas Bachem <mail@thomasbachem.com>\n\n\"git merge\" saves any uncommitted changes with \"git stash\" before it\ntries a merge strategy. When the strategy does not handle the merge,\nit restores them with \"git stash apply --index\". If some of the\nchanges are staged, that runs \"git reset\", which writes an entry to\nthe reflog of HEAD. The autostash tests in this script run eight such\nmerges.\n\nAn upcoming change makes \"git stash apply --index\" merge the index\nin-core, so it no longer runs \"git reset\" and those entries go away.\nAnother makes the default \"merge\" backend of \"git rebase\" run auto\nmaintenance when it finishes. Together, they change when auto\nmaintenance expires all reflogs, which it does once a hundred entries\nin the reflog of HEAD are due to expire.\n\nWith both, the expiry comes at the end of the \"git pull --rebase\" in\nthe \"--rebase with rebased upstream\" test. The \"git pull --rebase -f\"\nin the next test looks for the fork point in the reflog of\nrefs/remotes/me/copy, but as the test suite dates every reflog entry\nto 2005, the expiry has emptied that reflog. Pull then finds no fork\npoint, so the rebase also replays copy-orig, the commit \"copy\" was\nrewound from, and it conflicts.\n\nDisable reflog expiration in this script, as ea7d894f44 (t34xx: don't\nexpire reflogs where it matters, 2026-02-24) did for the rebase tests,\nso that the test no longer depends on where the expiry falls.\n\nReported-by: Junio C Hamano <gitster@pobox.com>\nHelped-by: D. Ben Knoble <ben.knoble@gmail.com>\nHelped-by: Phillip Wood <phillip.wood@dunelm.org.uk>\nAssisted-by: Claude Fable 5.1\nSigned-off-by: Thomas Bachem <mail@thomasbachem.com>\n---\n    t5520: don't expire reflogs where it matters\n    \n    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n    \n    Changes since v1: only the commit message, rewritten along the points\n    Phillip raised on Ben's copy of this patch:\n    https://lore.kernel.org/git/3547f4aa-649a-4f46-868c-0e50dfa69466@gmail.com/\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/2243\n\nRange-diff vs v1:\n\n 1:  1d8d6ed7f1 ! 1:  6699f3782e t5520: don't expire reflogs where it matters\n     @@ Metadata\n       ## Commit message ##\n          t5520: don't expire reflogs where it matters\n      \n     -    The \"--rebase -f with rebased upstream\" test computes its fork point\n     -    from the reflog of refs/remotes/me/copy, and the entry it needs is\n     -    the one that the fetch of the test before it wrote. Like every reflog\n     -    entry the suite writes after test_tick, it is dated 2005, so the\n     -    first \"git reflog expire --all\" after that fetch removes it. Pull\n     -    then finds no fork point and rebases onto the merge head with the\n     -    merge head as the upstream, and the rewound commits come back as a\n     -    conflict.\n     +    \"git merge\" saves any uncommitted changes with \"git stash\" before it\n     +    tries a merge strategy. When the strategy does not handle the merge,\n     +    it restores them with \"git stash apply --index\". If some of the\n     +    changes are staged, that runs \"git reset\", which writes an entry to\n     +    the reflog of HEAD. The autostash tests in this script run eight such\n     +    merges.\n      \n     -    Since 452b12c2e0 (builtin/maintenance: use \"geometric\" strategy by\n     -    default, 2026-02-24) auto maintenance runs that expiry once the reflog\n     -    of HEAD holds a hundred entries it would remove, the default of\n     -    maintenance.reflog-expire.auto. Which run crosses the threshold\n     -    depends on the entries and maintenance runs before it, so the script\n     -    passed by chance: a stash topic that no longer runs \"git reset\" from\n     -    \"stash apply --index\" and a rebase topic that runs auto maintenance\n     -    at the end of \"git rebase\" together move the expiry between the two\n     -    tests.\n     +    An upcoming change makes \"git stash apply --index\" merge the index\n     +    in-core, so it no longer runs \"git reset\" and those entries go away.\n     +    Another makes the default \"merge\" backend of \"git rebase\" run auto\n     +    maintenance when it finishes. Together, they change when auto\n     +    maintenance expires all reflogs, which it does once a hundred entries\n     +    in the reflog of HEAD are due to expire.\n      \n     -    Pin the expiry as ea7d894f44 (t34xx: don't expire reflogs where it\n     -    matters, 2026-02-24) did for the rebase tests. That covers a \"git gc\"\n     -    as well, which expires reflogs on its own, where turning off the auto\n     -    trigger of the reflog-expire task alone would not.\n     +    With both, the expiry comes at the end of the \"git pull --rebase\" in\n     +    the \"--rebase with rebased upstream\" test. The \"git pull --rebase -f\"\n     +    in the next test looks for the fork point in the reflog of\n     +    refs/remotes/me/copy, but as the test suite dates every reflog entry\n     +    to 2005, the expiry has emptied that reflog. Pull then finds no fork\n     +    point, so the rebase also replays copy-orig, the commit \"copy\" was\n     +    rewound from, and it conflicts.\n     +\n     +    Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't\n     +    expire reflogs where it matters, 2026-02-24) did for the rebase tests,\n     +    so that the test no longer depends on where the expiry falls.\n      \n          Reported-by: Junio C Hamano <gitster@pobox.com>\n          Helped-by: D. Ben Knoble <ben.knoble@gmail.com>\n\n\n t/t5520-pull.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 27f38ab3c8..bc818605a5 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -35,6 +35,12 @@ test_pull_autostash_fail () {\n }\n \n test_expect_success setup '\n+\t# Commit dates are hardcoded to 2005, and the reflog entries will have\n+\t# a matching timestamp. Maintenance may thus immediately expire\n+\t# reflogs if it was running.\n+\tgit config set gc.reflogExpire never &&\n+\tgit config set gc.reflogExpireUnreachable never &&\n+\n \techo file >file &&\n \tgit add file &&\n \tgit commit -a -m original\n\nbase-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3\n-- \ngitgitgadget\n"},{"id":"553659","messageId":"xmqq4if7effd.fsf@gitster.g","threadId":"66407","inReplyTo":"xmqqzex0hzhf.fsf@gitster.g","subject":"Re: [PATCH] t5520: don't expire reflogs where it matters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-30T00:44:22Z","receivedAt":"2026-09-30T00:44:27Z","isPatch":true,"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Either would work for me, but I created a synthetic base that\n> includes this patch and queued your last iteration on top of it,\n> before merging the result to 'seen' .\n>\n> When you reroll, I'd reuse this synthetic base 4d7270214a (Merge\n> branch 'tb/t5520-reflog-expire' into dk/stash-apply-index-incore,\n> 2026-09-28)\n\nAs Thomas updated the patch, I also had to update the synthetic\nbase.  It is now 59d1ce1b6e (Merge branch 'tb/t5520-reflog-expire'\ninto dk/stash-apply-index-incore, 2026-09-29).\n"},{"id":"553721","messageId":"8b81c508-ac67-498d-b78f-a4b5dab8c198@gmail.com","threadId":"66407","inReplyTo":"pull.2243.v2.git.1790701691022.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] t5520: don't expire reflogs where it matters","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-09-30T15:49:26Z","receivedAt":"2026-09-30T15:49:38Z","isPatch":true,"body":"Hi Thomas\n\nThanks for rewording this, it is much better now, but the comment about \nautostash at the end of the first paragraph is incorrect I think. As I \nthink we need to fix that I've left a couple of other suggestions as well.\n\nOn 29/09/2026 18:08, Thomas Bachem via GitGitGadget wrote:\n> From: Thomas Bachem <mail@thomasbachem.com>\n> \n> \"git merge\" saves any uncommitted changes with \"git stash\" before it\n> tries a merge strategy. When the strategy does not handle the merge,\n> it restores them with \"git stash apply --index\". If some of the\n> changes are staged, that runs \"git reset\", which writes an entry to\n> the reflog of HEAD. \n\nUp to here it all makes sense\nThe autostash tests in this script run eight such merges.\n\nThis doesn't make sense to me. The tests that use \"--autostash\" will \nclear any changes from the index and worktree and so will never need to \nstash anything while trying different merge strategies which means those \ntests do not run \"git stash apply --index\".\n> \n> An upcoming change makes \"git stash apply --index\" merge the index\n> in-core, so it no longer runs \"git reset\" and those entries go away.\n> Another makes the default \"merge\" backend of \"git rebase\" run auto\n> maintenance when it finishes. Together, they change when auto\n> maintenance expires all reflogs, which it does once a hundred entries\n> in the reflog of HEAD are due to expire.\n\nThe second half of this sentence is true, but I'm not sure it is very \nrelevant, all that really matters is that we're triggering \"git reflog \nexpire\" at a different point in the test run which is already explained \nby the first half.\n\n> With both, the expiry comes at the end of the \"git pull --rebase\" in\n\n\"With both\" sounds a bit strange to me. Maybe\n\nThis means that unfortunately the reflogs are expired at the end of \"git \npull --rebase\" in ...\n\n> the \"--rebase with rebased upstream\" test. The \"git pull --rebase -f\"\n> in the next test looks for the fork point in the reflog of\n> refs/remotes/me/copy, but as the test suite dates every reflog entry\n> to 2005, the expiry has emptied that reflog. Pull then finds no fork\n> point, so the rebase also replays copy-orig, the commit \"copy\" was\n> rewound from, and it conflicts.\n\nGood explanation\n\n> Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't\n> expire reflogs where it matters, 2026-02-24) did for the rebase tests,\n> so that the test no longer depends on where the expiry falls.\n\nAlso good\n\nThanks\n\nPhillip\n\n> Reported-by: Junio C Hamano <gitster@pobox.com>\n> Helped-by: D. Ben Knoble <ben.knoble@gmail.com>\n> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>\n> Assisted-by: Claude Fable 5.1\n> Signed-off-by: Thomas Bachem <mail@thomasbachem.com>\n> ---\n>      t5520: don't expire reflogs where it matters\n>      \n>      The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n>      bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n>      https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n>      \n>      Changes since v1: only the commit message, rewritten along the points\n>      Phillip raised on Ben's copy of this patch:\n>      https://lore.kernel.org/git/3547f4aa-649a-4f46-868c-0e50dfa69466@gmail.com/\n> \n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v2\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v2\n> Pull-Request: https://github.com/gitgitgadget/git/pull/2243\n> \n> Range-diff vs v1:\n> \n>   1:  1d8d6ed7f1 ! 1:  6699f3782e t5520: don't expire reflogs where it matters\n>       @@ Metadata\n>         ## Commit message ##\n>            t5520: don't expire reflogs where it matters\n>        \n>       -    The \"--rebase -f with rebased upstream\" test computes its fork point\n>       -    from the reflog of refs/remotes/me/copy, and the entry it needs is\n>       -    the one that the fetch of the test before it wrote. Like every reflog\n>       -    entry the suite writes after test_tick, it is dated 2005, so the\n>       -    first \"git reflog expire --all\" after that fetch removes it. Pull\n>       -    then finds no fork point and rebases onto the merge head with the\n>       -    merge head as the upstream, and the rewound commits come back as a\n>       -    conflict.\n>       +    \"git merge\" saves any uncommitted changes with \"git stash\" before it\n>       +    tries a merge strategy. When the strategy does not handle the merge,\n>       +    it restores them with \"git stash apply --index\". If some of the\n>       +    changes are staged, that runs \"git reset\", which writes an entry to\n>       +    the reflog of HEAD. The autostash tests in this script run eight such\n>       +    merges.\n>        \n>       -    Since 452b12c2e0 (builtin/maintenance: use \"geometric\" strategy by\n>       -    default, 2026-02-24) auto maintenance runs that expiry once the reflog\n>       -    of HEAD holds a hundred entries it would remove, the default of\n>       -    maintenance.reflog-expire.auto. Which run crosses the threshold\n>       -    depends on the entries and maintenance runs before it, so the script\n>       -    passed by chance: a stash topic that no longer runs \"git reset\" from\n>       -    \"stash apply --index\" and a rebase topic that runs auto maintenance\n>       -    at the end of \"git rebase\" together move the expiry between the two\n>       -    tests.\n>       +    An upcoming change makes \"git stash apply --index\" merge the index\n>       +    in-core, so it no longer runs \"git reset\" and those entries go away.\n>       +    Another makes the default \"merge\" backend of \"git rebase\" run auto\n>       +    maintenance when it finishes. Together, they change when auto\n>       +    maintenance expires all reflogs, which it does once a hundred entries\n>       +    in the reflog of HEAD are due to expire.\n>        \n>       -    Pin the expiry as ea7d894f44 (t34xx: don't expire reflogs where it\n>       -    matters, 2026-02-24) did for the rebase tests. That covers a \"git gc\"\n>       -    as well, which expires reflogs on its own, where turning off the auto\n>       -    trigger of the reflog-expire task alone would not.\n>       +    With both, the expiry comes at the end of the \"git pull --rebase\" in\n>       +    the \"--rebase with rebased upstream\" test. The \"git pull --rebase -f\"\n>       +    in the next test looks for the fork point in the reflog of\n>       +    refs/remotes/me/copy, but as the test suite dates every reflog entry\n>       +    to 2005, the expiry has emptied that reflog. Pull then finds no fork\n>       +    point, so the rebase also replays copy-orig, the commit \"copy\" was\n>       +    rewound from, and it conflicts.\n>       +\n>       +    Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't\n>       +    expire reflogs where it matters, 2026-02-24) did for the rebase tests,\n>       +    so that the test no longer depends on where the expiry falls.\n>        \n>            Reported-by: Junio C Hamano <gitster@pobox.com>\n>            Helped-by: D. Ben Knoble <ben.knoble@gmail.com>\n> \n> \n>   t/t5520-pull.sh | 6 ++++++\n>   1 file changed, 6 insertions(+)\n> \n> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\n> index 27f38ab3c8..bc818605a5 100755\n> --- a/t/t5520-pull.sh\n> +++ b/t/t5520-pull.sh\n> @@ -35,6 +35,12 @@ test_pull_autostash_fail () {\n>   }\n>   \n>   test_expect_success setup '\n> +\t# Commit dates are hardcoded to 2005, and the reflog entries will have\n> +\t# a matching timestamp. Maintenance may thus immediately expire\n> +\t# reflogs if it was running.\n> +\tgit config set gc.reflogExpire never &&\n> +\tgit config set gc.reflogExpireUnreachable never &&\n> +\n>   \techo file >file &&\n>   \tgit add file &&\n>   \tgit commit -a -m original\n> \n> base-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3\n\n"},{"id":"553815","messageId":"CAA0xjtrDQTOGO_6x7fSfHEM_2kBkyy78NcVGtTtUrSBhw=CEzg@mail.gmail.com","threadId":"66407","inReplyTo":"8b81c508-ac67-498d-b78f-a4b5dab8c198@gmail.com","subject":"Re: [PATCH v2] t5520: don't expire reflogs where it matters","fromName":"Thomas Bachem","fromEmail":"mail@thomasbachem.com","sentAt":"2026-10-01T08:07:53Z","receivedAt":"2026-10-01T08:08:05Z","isPatch":true,"body":"Hi Phillip,\n\nOn 30/09/2026 16:49, Phillip Wood wrote:\n> This doesn't make sense to me. The tests that use \"--autostash\" will\n> clear any changes from the index and worktree and so will never need to\n> stash anything while trying different merge strategies which means those\n> tests do not run \"git stash apply --index\".\n\nYou're right. On Monday I wrote that the merges don't come from the\nautostash tests [1], and in v2 that they do. Neither was exact.\n\nThey come from the tests that pull with autostash disabled.\ntest_pull_autostash_fail stages a new file and expects the pull to\nfail, and eight of its calls merge rather than rebase, with\n\"--no-autostash\" or with pull.autostash set to false. The staged file\nis still there when \"git merge\" starts, so merge stashes it itself and\nrestores it with \"git stash apply --index\" when the strategy does not\nhandle the merge. The tests that do autostash never get there, as you\nsay.\n\nI'll say it like this in v3: \"The tests that pull with autostash\ndisabled run eight such merges, each with a new file staged.\"\n\n> The second half of this sentence is true, but I'm not sure it is very\n> relevant, all that really matters is that we're triggering \"git reflog\n> expire\" at a different point in the test run which is already explained\n> by the first half.\n\nI'll drop it.\n\n> \"With both\" sounds a bit strange to me. Maybe\n>\n> This means that unfortunately the reflogs are expired at the end of \"git\n> pull --rebase\" in ...\n\nI'll take that.\n\nThanks,\nThomas\n\n[1] <CAA0xjtpzaWH10pHOQ5j-5Hp1yHEKTDFbsicG6E4w=5nxb_irWw@mail.gmail.com>\n"},{"id":"553817","messageId":"pull.2243.v3.git.1790843056949.gitgitgadget@gmail.com","threadId":"66407","inReplyTo":"pull.2243.git.1790606282769.gitgitgadget@gmail.com","subject":"[PATCH v3] t5520: don't expire reflogs where it matters","fromName":"Thomas Bachem via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-10-01T08:24:16Z","receivedAt":"2026-10-01T08:24:20Z","isPatch":true,"body":"From: Thomas Bachem <mail@thomasbachem.com>\n\n\"git merge\" saves any uncommitted changes with \"git stash\" before it\ntries a merge strategy. When the strategy does not handle the merge,\nit restores them with \"git stash apply --index\". If some of the\nchanges are staged, that runs \"git reset\", which writes an entry to\nthe reflog of HEAD. The tests that pull with autostash disabled run\neight such merges, each with a new file staged.\n\nAn upcoming change makes \"git stash apply --index\" merge the index\nin-core, so it no longer runs \"git reset\" and those entries go away.\nAnother makes the default \"merge\" backend of \"git rebase\" run auto\nmaintenance when it finishes. Together, they change when auto\nmaintenance expires the reflogs.\n\nThis means that unfortunately the reflogs are expired at the end of\n\"git pull --rebase\" in the \"--rebase with rebased upstream\" test. The\n\"git pull --rebase -f\" in the next test looks for the fork point in\nthe reflog of refs/remotes/me/copy, but as the test suite dates every\nreflog entry to 2005, the expiry has emptied that reflog. Pull then\nfinds no fork point, so the rebase also replays copy-orig, the commit\n\"copy\" was rewound from, and it conflicts.\n\nDisable reflog expiration in this script, as ea7d894f44 (t34xx: don't\nexpire reflogs where it matters, 2026-02-24) did for the rebase tests,\nso that the test no longer depends on where the expiry falls.\n\nReported-by: Junio C Hamano <gitster@pobox.com>\nHelped-by: D. Ben Knoble <ben.knoble@gmail.com>\nHelped-by: Phillip Wood <phillip.wood@dunelm.org.uk>\nAssisted-by: Claude Fable 5.1\nSigned-off-by: Thomas Bachem <mail@thomasbachem.com>\n---\n    t5520: don't expire reflogs where it matters\n    \n    The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n    bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n    https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n    \n    Changes since v2: only the commit message. I had the eight merges in the\n    wrong tests: they come from the pulls with autostash disabled, where\n    \"git merge\" stashes and restores the staged file itself. I also dropped\n    the clause about the hundred entries and took Phillip's opening for the\n    third paragraph, all from his review:\n    https://lore.kernel.org/git/8b81c508-ac67-498d-b78f-a4b5dab8c198@gmail.com/\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v3\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v3\nPull-Request: https://github.com/gitgitgadget/git/pull/2243\n\nRange-diff vs v2:\n\n 1:  6699f3782e ! 1:  be6c3f21c5 t5520: don't expire reflogs where it matters\n     @@ Commit message\n          tries a merge strategy. When the strategy does not handle the merge,\n          it restores them with \"git stash apply --index\". If some of the\n          changes are staged, that runs \"git reset\", which writes an entry to\n     -    the reflog of HEAD. The autostash tests in this script run eight such\n     -    merges.\n     +    the reflog of HEAD. The tests that pull with autostash disabled run\n     +    eight such merges, each with a new file staged.\n      \n          An upcoming change makes \"git stash apply --index\" merge the index\n          in-core, so it no longer runs \"git reset\" and those entries go away.\n          Another makes the default \"merge\" backend of \"git rebase\" run auto\n          maintenance when it finishes. Together, they change when auto\n     -    maintenance expires all reflogs, which it does once a hundred entries\n     -    in the reflog of HEAD are due to expire.\n     +    maintenance expires the reflogs.\n      \n     -    With both, the expiry comes at the end of the \"git pull --rebase\" in\n     -    the \"--rebase with rebased upstream\" test. The \"git pull --rebase -f\"\n     -    in the next test looks for the fork point in the reflog of\n     -    refs/remotes/me/copy, but as the test suite dates every reflog entry\n     -    to 2005, the expiry has emptied that reflog. Pull then finds no fork\n     -    point, so the rebase also replays copy-orig, the commit \"copy\" was\n     -    rewound from, and it conflicts.\n     +    This means that unfortunately the reflogs are expired at the end of\n     +    \"git pull --rebase\" in the \"--rebase with rebased upstream\" test. The\n     +    \"git pull --rebase -f\" in the next test looks for the fork point in\n     +    the reflog of refs/remotes/me/copy, but as the test suite dates every\n     +    reflog entry to 2005, the expiry has emptied that reflog. Pull then\n     +    finds no fork point, so the rebase also replays copy-orig, the commit\n     +    \"copy\" was rewound from, and it conflicts.\n      \n          Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't\n          expire reflogs where it matters, 2026-02-24) did for the rebase tests,\n\n\n t/t5520-pull.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 27f38ab3c8..bc818605a5 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -35,6 +35,12 @@ test_pull_autostash_fail () {\n }\n \n test_expect_success setup '\n+\t# Commit dates are hardcoded to 2005, and the reflog entries will have\n+\t# a matching timestamp. Maintenance may thus immediately expire\n+\t# reflogs if it was running.\n+\tgit config set gc.reflogExpire never &&\n+\tgit config set gc.reflogExpireUnreachable never &&\n+\n \techo file >file &&\n \tgit add file &&\n \tgit commit -a -m original\n\nbase-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3\n-- \ngitgitgadget\n"},{"id":"553841","messageId":"667a68a1-641f-46c4-a718-8dd81d5c219f@gmail.com","threadId":"66407","inReplyTo":"pull.2243.v3.git.1790843056949.gitgitgadget@gmail.com","subject":"Re: [PATCH v3] t5520: don't expire reflogs where it matters","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-10-01T15:48:35Z","receivedAt":"2026-10-01T15:48:45Z","isPatch":true,"body":"Hi Thomas\n\nThis looks good. Thanks for the patch and also your help finding where \nthe difference in reflog entry count was coming from - before your mail, \nI did not realize that \"git merge\" stashed changes without \"--autostash\".\n\nPhillip\n\nOn 01/10/2026 09:24, Thomas Bachem via GitGitGadget wrote:\n> From: Thomas Bachem <mail@thomasbachem.com>\n> \n> \"git merge\" saves any uncommitted changes with \"git stash\" before it\n> tries a merge strategy. When the strategy does not handle the merge,\n> it restores them with \"git stash apply --index\". If some of the\n> changes are staged, that runs \"git reset\", which writes an entry to\n> the reflog of HEAD. The tests that pull with autostash disabled run\n> eight such merges, each with a new file staged.\n> \n> An upcoming change makes \"git stash apply --index\" merge the index\n> in-core, so it no longer runs \"git reset\" and those entries go away.\n> Another makes the default \"merge\" backend of \"git rebase\" run auto\n> maintenance when it finishes. Together, they change when auto\n> maintenance expires the reflogs.\n> \n> This means that unfortunately the reflogs are expired at the end of\n> \"git pull --rebase\" in the \"--rebase with rebased upstream\" test. The\n> \"git pull --rebase -f\" in the next test looks for the fork point in\n> the reflog of refs/remotes/me/copy, but as the test suite dates every\n> reflog entry to 2005, the expiry has emptied that reflog. Pull then\n> finds no fork point, so the rebase also replays copy-orig, the commit\n> \"copy\" was rewound from, and it conflicts.\n> \n> Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't\n> expire reflogs where it matters, 2026-02-24) did for the rebase tests,\n> so that the test no longer depends on where the expiry falls.\n> \n> Reported-by: Junio C Hamano <gitster@pobox.com>\n> Helped-by: D. Ben Knoble <ben.knoble@gmail.com>\n> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>\n> Assisted-by: Claude Fable 5.1\n> Signed-off-by: Thomas Bachem <mail@thomasbachem.com>\n> ---\n>      t5520: don't expire reflogs where it matters\n>      \n>      The t5520 failure Junio saw in 'seen' with Ben Knoble's stash series,\n>      bisected by Ben to tb/rerere-lock-grace and taken apart in the thread:\n>      https://lore.kernel.org/git/a59c4225-f093-4001-b77a-2083dfecce6e@gmail.com/\n>      \n>      Changes since v2: only the commit message. I had the eight merges in the\n>      wrong tests: they come from the pulls with autostash disabled, where\n>      \"git merge\" stashes and restores the staged file itself. I also dropped\n>      the clause about the hundred entries and took Phillip's opening for the\n>      third paragraph, all from his review:\n>      https://lore.kernel.org/git/8b81c508-ac67-498d-b78f-a4b5dab8c198@gmail.com/\n> \n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2243%2Fthomasbachem%2Ft5520-reflog-expire-v3\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2243/thomasbachem/t5520-reflog-expire-v3\n> Pull-Request: https://github.com/gitgitgadget/git/pull/2243\n> \n> Range-diff vs v2:\n> \n>   1:  6699f3782e ! 1:  be6c3f21c5 t5520: don't expire reflogs where it matters\n>       @@ Commit message\n>            tries a merge strategy. When the strategy does not handle the merge,\n>            it restores them with \"git stash apply --index\". If some of the\n>            changes are staged, that runs \"git reset\", which writes an entry to\n>       -    the reflog of HEAD. The autostash tests in this script run eight such\n>       -    merges.\n>       +    the reflog of HEAD. The tests that pull with autostash disabled run\n>       +    eight such merges, each with a new file staged.\n>        \n>            An upcoming change makes \"git stash apply --index\" merge the index\n>            in-core, so it no longer runs \"git reset\" and those entries go away.\n>            Another makes the default \"merge\" backend of \"git rebase\" run auto\n>            maintenance when it finishes. Together, they change when auto\n>       -    maintenance expires all reflogs, which it does once a hundred entries\n>       -    in the reflog of HEAD are due to expire.\n>       +    maintenance expires the reflogs.\n>        \n>       -    With both, the expiry comes at the end of the \"git pull --rebase\" in\n>       -    the \"--rebase with rebased upstream\" test. The \"git pull --rebase -f\"\n>       -    in the next test looks for the fork point in the reflog of\n>       -    refs/remotes/me/copy, but as the test suite dates every reflog entry\n>       -    to 2005, the expiry has emptied that reflog. Pull then finds no fork\n>       -    point, so the rebase also replays copy-orig, the commit \"copy\" was\n>       -    rewound from, and it conflicts.\n>       +    This means that unfortunately the reflogs are expired at the end of\n>       +    \"git pull --rebase\" in the \"--rebase with rebased upstream\" test. The\n>       +    \"git pull --rebase -f\" in the next test looks for the fork point in\n>       +    the reflog of refs/remotes/me/copy, but as the test suite dates every\n>       +    reflog entry to 2005, the expiry has emptied that reflog. Pull then\n>       +    finds no fork point, so the rebase also replays copy-orig, the commit\n>       +    \"copy\" was rewound from, and it conflicts.\n>        \n>            Disable reflog expiration in this script, as ea7d894f44 (t34xx: don't\n>            expire reflogs where it matters, 2026-02-24) did for the rebase tests,\n> \n> \n>   t/t5520-pull.sh | 6 ++++++\n>   1 file changed, 6 insertions(+)\n> \n> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\n> index 27f38ab3c8..bc818605a5 100755\n> --- a/t/t5520-pull.sh\n> +++ b/t/t5520-pull.sh\n> @@ -35,6 +35,12 @@ test_pull_autostash_fail () {\n>   }\n>   \n>   test_expect_success setup '\n> +\t# Commit dates are hardcoded to 2005, and the reflog entries will have\n> +\t# a matching timestamp. Maintenance may thus immediately expire\n> +\t# reflogs if it was running.\n> +\tgit config set gc.reflogExpire never &&\n> +\tgit config set gc.reflogExpireUnreachable never &&\n> +\n>   \techo file >file &&\n>   \tgit add file &&\n>   \tgit commit -a -m original\n> \n> base-commit: 34f06850c16c7f7ac822b1adc71354f11b0f2ca3\n\n"},{"id":"553933","messageId":"CAA0xjtpM6t-Ga57UF0yrv7=ggz5GChHSk7hTQnGbVfAykhVmQw@mail.gmail.com","threadId":"66407","inReplyTo":"pull.2243.v3.git.1790843056949.gitgitgadget@gmail.com","subject":"Re: [PATCH v3] t5520: don't expire reflogs where it matters","fromName":"Thomas Bachem","fromEmail":"mail@thomasbachem.com","sentAt":"2026-10-02T09:23:49Z","receivedAt":"2026-10-02T09:24:01Z","isPatch":true,"body":"Hi Junio,\n\nOn 02/10/2026 00:48, Junio C Hamano wrote in What's cooking [1]:\n> The t5520 test script has been updated to disable reflog expiration.\n> This prevents test flakiness caused by auto-maintenance running\n> geometric repack which would otherwise immediately expire the test's\n> reflogs due to them carrying hardcoded timestamps from 2005.\n\nIt's the reflog-expire task of auto maintenance that expires the\nreflogs, not the geometric repack.\n\nThanks,\nThomas\n\n[1] <xmqqv77l2g2e.fsf@gitster.g>\n"},{"id":"553975","messageId":"xmqqfqyo16vi.fsf@gitster.g","threadId":"66407","inReplyTo":"CAA0xjtpM6t-Ga57UF0yrv7=ggz5GChHSk7hTQnGbVfAykhVmQw@mail.gmail.com","subject":"Re: [PATCH v3] t5520: don't expire reflogs where it matters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-02T15:04:17Z","receivedAt":"2026-10-02T15:04:20Z","isPatch":true,"body":"Thomas Bachem <mail@thomasbachem.com> writes:\n\n> Hi Junio,\n>\n> On 02/10/2026 00:48, Junio C Hamano wrote in What's cooking [1]:\n>> The t5520 test script has been updated to disable reflog expiration.\n>> This prevents test flakiness caused by auto-maintenance running\n>> geometric repack which would otherwise immediately expire the test's\n>> reflogs due to them carrying hardcoded timestamps from 2005.\n>\n> It's the reflog-expire task of auto maintenance that expires the\n> reflogs, not the geometric repack.\n\nIndeed.  Thanks.\n"}]}