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
