Re: [PATCH v3 0/5] stash: clean up index-mode test merge

On Mon, Sep 28, 2026 at 5:50 AM Phillip Wood [off-list ref] wrote:

On 27/09/2026 20:21, Junio C Hamano wrote:

quoted

"D. Ben Knoble" [off-list ref] writes:

quoted

Hi all,

This small patch series fixes a bug reported by Eli Barzilay in the
interaction between autostashing, staged index entries, and
stash.index=true.

The first patch is an incidental cleanup, and the second re-arranges one
line to make the change easier. The third and fourth add missing test
coverage (which catch breakages from prior incorrect rounds of this
series), while the last holds the interesting bits.

I may have reported this on the previous round, too, but 'seen'
seems to break t5520 when this topic is merged.  I'll eject the
topic from my tree for now in the meantime.

First I'm hearing about it, but I'll try to bisect seen and see what I can find.

I'm a bit stumped by that as the failing test (5520.69 '--rebase -f with
rebased upstream') does not stash anything.

I wonder if a prior test is affected "silently" and we only find out by .69?

There seems to be something
funny going on with pull's fork-point detection. If I add GIT_TRACE=1 to
"git pull --rebase" then on 'seen' I see

trace: built-in: git rebase --no-autostash --onto
ae9857430e281d178a3755aecfc5e29c46a02306
f29aa667ce68e4d514557081ca7f54b12e108922

but with this series I see

trace: built-in: git rebase --no-autostash --onto
ae9857430e281d178a3755aecfc5e29c46a02306
ae9857430e281d178a3755aecfc5e29c46a02306

so the upstream commit has changed. The previous test also checks the
fork-point behavior and the failing test just runs "git reset --hard" at
the start rather than re-creating the reflogs which seems a bit iffy to
me but I've no idea why this series causes it to fail. I tried a merge
of 'master' and 'seen' just in case the failure was caused by the base
I'd used for this series but that passes.

Thanks Phillip!

-- 
D. Ben Knoble