Re: [perf] git log --follow seems slow

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

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