Re: [PATCH v3 0/5] stash: clean up index-mode test merge
On Mon, Sep 28, 2026 at 5:50 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
Show 18 quoted lines
>
> On 27/09/2026 20:21, Junio C Hamano wrote:
> > "D. Ben Knoble" <ben.knoble@gmail.com> 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.
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?
Show 20 quoted lines
> 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.
--
D. Ben Knoble
D. Ben Knoble <ben.knoble@gmail.com>