From: Phillip Wood Date: Mon, 28 Sep 2026 09:50:13 GMT Subject: Re: [PATCH v3 0/5] stash: clean up index-mode test merge Message-ID: <346c4209-9600-4302-817f-e8f6b364ce6a@gmail.com> In-Reply-To: On 27/09/2026 20:21, Junio C Hamano wrote: > "D. Ben Knoble" writes: > >> 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. I'm a bit stumped by that as the failing test (5520.69 '--rebase -f with rebased upstream') does not stash anything. 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