Re: [PATCH v5 0/5] log: speed up --follow following renames for non-linear history

[Patrick Steinhardt <ps@pks.im>]

On Wed, Nov 11, 2026 at 12:41:21PM +0000, Miklos Vajna wrote:
> On Wed, Nov 11, 2026 at 11:43:50AM +0100, Patrick Steinhardt <ps@pks.im> wrote:
[snip]
> > I don't want to make you (Miklos) responsible for delivering that of
> > course, I just want us to align on a fast path forward. In case we don't
> > revert we can help out and contribute such a default-disabled toggle.
> > And if so, that would also give us more time to fix the issue properly.
> 
> Yes, aligning on what we want would be good. :-) I'm OK to replace the
> last patch in the series with a patch that turns this off by default,
> but then how to opt in, would be be fine to have a new config option for
> this (similar to log.follow)? Would that do what you need or you want
> something else?

I don't really have a good sense of how far this patch series is on its
road to getting merged. So how about we first land a single-patch series
that introduces the knob that we can merge without the remaining parts
in this series here?

  (For context, we deploy from Git's master branch at GitLab, and hence
  my desire to have this regression fixed fast. As said, I'm happy to
  help out with that, I don't want to push the whole burden on you
  here.)

With regards to how to opt-in, I can see two ways:

  - We could extend "--follow" to take an optional parameter so that the
    user can pass "--follow=merges". Same with "log.follow", we could
    teach it another option "merges".

  - We could introduce "--follow-merges" and "log.followMerges".

I'm leaning towards the first option myself.

Thanks!

Patrick