On Wed, Jun 25, 2025 at 12:44:16PM -0400, Kai Koponen wrote:

- --follow is not taking advantage of the commit graph (seems likely
as --follow seems equally slow with core.commitGraph off)

It's mostly this. History pruning is disabled with --follow, since the
path of interest may change as we traverse through history. And the use
of commit graph changed-path bloom filters is tied to the pruning code.
So this hits you two-fold:

  1. For each commit we visit, we actually do a tree diff to see if it
     touched that path (leaving aside rename detection, we still have to
     open the trees down to the path of interest).

  2. We don't prune side-branches of history, so we are visiting more
     commits. Normally when we see a merge of two branches, when one
     parent matches the merge result and the other does not, we know
     that nothing interesting happened on the side branch. So we do not
     traverse those commits at all. But with pruning disabled, that no
     longer happens.

These limitations are mostly due to the hacky way that --follow is
bolted on to the traversal machinery. The "right" way for --follow to
work is to keep a unique pathspec (and bloom filter) for each line of
commits, passing it down as we walk backwards through history (and
modifying it when we see a rename).

It's probably possible to bolt bloom-filter checks onto the existing
--follow feature, but it would probably involve a lot of special casing.

-Peff