Derrick Stolee <dsto...@microsoft.com> writes:
> On the Linux repository, performance tests were run for the following
> git log --graph --oneline -1000
> Before: 0.92s
> After: 0.66s
> Rel %: -28.3%
> Adding '-- kernel/' to the command requires loading the root tree
> for every commit that is walked. There was no measureable performance
> change as a result of this patch.
In the "Git Merge contributor summit notes"  one can read that:
> - VSTS adds bloom filters to know which paths have changed on the commit
> - tree-same check in the bloom filter is fast; speeds up file history checks
> - if the file history is _very_ sparse, then bloom filter is useful
Could this method speed up also the second case mentioned here? Can
anyone explain how this "path-changed bloom filter" works in VSTS?
Could we add something like this to the commit-graph file?