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

From: Thomas Bachem <mail@thomasbachem.com>
Date: Oct 1, 2026, 08:07 UTC
Message-ID: <CAA0xjtrDQTOGO_6x7fSfHEM_2kBkyy78NcVGtTtUrSBhw=CEzg@mail.gmail.com>
In-Reply-To: <8b81c508-ac67-498d-b78f-a4b5dab8c198@gmail.com>

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>