Re: [PATCH v3 0/5] stash: clean up index-mode test merge
On Mon, Sep 28, 2026 at 11:36 AM D. Ben Knoble <ben.knoble@gmail.com> wrote:
Show 19 quoted lines
>
> Let me see if I understand correctly…
>
> On Mon, Sep 28, 2026 at 10:50 AM Thomas Bachem <mail@thomasbachem.com> wrote:
> >
> > On Mon, Sep 28, 2026 at 3:45 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
> > > Oh, when I was thinking about this over lunch I did wonder if that might
> > > be the culprit. Previously we didn't run "git maintenance --auto" after
> > > a rebase with the 'merge' backend but with that topic we do, and because
> > > we set GIT_COMMITTER_DATE to sometime in 2005, if 'git reflog expire'
> > > gets triggered it will expire the reflog entries that 'git pull
> > > --rebase' relies on. As you suggested in another mail, I assume this
>
> > "git pull --rebase" computes the fork point before it fetches, from
> > the reflog of refs/remotes/me/copy,
>
> This is described by the manual for git-rebase under --fork-point,
> which is on unless we have an <upstream> or --keep-base (modulo
> config). Put a pin in this.
Show 9 quoted lines
> But here's what I can't figure out, returning to that pin from
> earlier: I was a bit surprised to see mention of rebase reading
> reflogs! When I remembered --fork-point, I was even more curious (but
> at least it's obvious that rebase will read the reflogs in some
> scenarios).
>
> What confuses me is that builtin/pull.c:run_rebase() sure looks like
> it provides an <upstream> to the command invocation, so shouldn't
> --fork-point and reflog use be disabled????
Indeed, from GIT_TRACE2 output I can see we do run
git rebase --no-autostash --onto ae98… f29a…
but well before that we run
git merge-base --fork-point refs/remotes/me/copy to-rebase
which is then presumably fed down to the rebase. Interesting.
--
D. Ben Knoble