t5520: don't expire reflogs where it matters - #2243
Open
thomasbachem wants to merge 1 commit into
Open
thomasbachem wants to merge 1 commit into
thomasbachem wants to merge 1 commit into
Conversation
Author
|
/preview |
|
Error: Message failed: 421-4.3.0 Temporary System Problem. Try again later. For more information, go to |
Author
|
/preview |
|
Preview email sent as pull.2243.git.1790606012483.gitgitgadget@gmail.com |
Author
|
/submit |
|
Submitted as pull.2243.git.1790606282769.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Ben Knoble wrote on the Git mailing list (how to reply to this email): > 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 |
|
"D. Ben Knoble" wrote on the Git mailing list (how to reply to this email): 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. |
thomasbachem
force-pushed
the
t5520-reflog-expire
branch
from
September 29, 2026 16:58
1d8d6ed to
6699f37
Compare
Author
|
/preview |
|
Preview email sent as pull.2243.v2.git.1790701167040.gitgitgadget@gmail.com |
Author
|
/submit |
|
Submitted as pull.2243.v2.git.1790701691022.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): 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 |
|
"D. Ben Knoble" wrote on the Git mailing list (how to reply to this email): 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 |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "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. |
|
This branch is now known as |
|
This patch series was integrated into seen via git@db938ca. |
|
This patch series is no longer integrated into seen. |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): 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). |
|
Phillip Wood wrote on the Git mailing list (how to reply to this email): 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 |
|
User |
|
This patch series was integrated into seen via git@4c42202. |
"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 ea7d894 (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>
thomasbachem
force-pushed
the
t5520-reflog-expire
branch
from
October 1, 2026 08:02
6699f37 to
be6c3f2
Compare
Author
|
/preview |
|
Preview email sent as pull.2243.v3.git.1790841878733.gitgitgadget@gmail.com |
Author
|
/submit |
|
Submitted as pull.2243.v3.git.1790843056949.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Thomas Bachem wrote on the Git mailing list (how to reply to this email): 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> |
|
Phillip Wood wrote on the Git mailing list (how to reply to this email): 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 |
|
This patch series is no longer integrated into seen. |
|
This patch series was integrated into seen via git@921c16a. |
|
There was a status update in the "New Topics" section about the branch 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. Will merge to 'next'? cf. <667a68a1-641f-46c4-a718-8dd81d5c219f@gmail.com> source: <pull.2243.v3.git.1790843056949.gitgitgadget@gmail.com> |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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/
Cc: D. Ben Knoble ben.knoble@gmail.com
Cc: Phillip Wood phillip.wood@dunelm.org.uk
Cc: Junio C Hamano gitster@pobox.com
Cc: Patrick Steinhardt ps@pks.im
cc: Phillip Wood phillip.wood123@gmail.com