Git blame MAINTAINERS >/dev/null Before: 20.1s This means that the cost of computing a diff relative to the pathspec is very small. I specifically looked for "deep" paths that were also edited many times.Īs a counterpoint, the MAINTAINERS file was edited many times but is located in the root tree. Git blame tools/perf/ui/stdio/hist.c >/dev/null Before: 0.27s Git blame kernel/time/time.c >/dev/null Before: 0.72s Git blame arch/x86/kernel/topology.c >/dev/null` Before: 0.83s Here are some example timings that I found by blaming some paths in the Linux kernel repository: If a repo has a commit-graph file with computed changed-path Bloom filters, then they should notice improved performance for their ' git blame' commands. Generally, this is a performance enhancement and should not change the behavior of ' git blame' in any way. Thus, the Bloom filter integration is explicitly disabled in this mode.Ī later change could expand the bloom_key data with an appropriate call (or calls) to add_bloom_key(). I do not know enough about how this happens in the blame machinery.
If a user requests copy detection using " git blame -C", then there are more places where the set of "important" files can expand. We then check to see if any of these keys answer "maybe" in the diff. But also, we need to add more keys to a list if a rename is detected. In order to make this work with the blame machinery, we need to initialize a struct bloom_key with the initial path. When this is the first parent, we can check the Bloom filters before calling diff_tree_oid(). When computing a blame, there is a section in find_origin() that computes a diff between a commit and one of its parents.
See commit 1b4c57f, commit 24b7d1e, commit fe88f9f () by Jeff King ( peff). With Git 2.27 (Q2 2020), " git blame" learns to take advantage of the " changed-paths" Bloom filter stored in the commit-graph file, and introduced with git log.
0 kommentar(er)
