From: D. Ben Knoble Date: Tue, 29 Sep 2026 11:38:40 GMT Subject: Re: [PATCH v3 0/5] stash: clean up index-mode test merge Message-ID: In-Reply-To: On Mon, Sep 28, 2026 at 11:36 AM D. Ben Knoble wrote: > > Let me see if I understand correctly… > > On Mon, Sep 28, 2026 at 10:50 AM Thomas Bachem wrote: > > > > On Mon, Sep 28, 2026 at 3:45 PM Phillip Wood 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 or --keep-base (modulo > config). Put a pin in this. > 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 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