Closed azanli closed 1 year ago
Hey Andy! Thank you for the PR.
I've looked into adding this in the past and decided against it for two reasons: 1) I don't know what performance impact it can have in massive git repositories and 2) I feel like I would need to add a file-path property in the blame message tokens. I don't want to struggle with more weird systems and their infinite quirks.
Do you know what the performance impact would be and have you looked into how the path would need to be rendered in a few different systems?
I've done some research and it looks like it adds a bit of overhead:
github/git/git $ time git blame builtin/blame.c > /dev/null
real 0m0.418s
user 0m0.328s
sys 0m0.089s
github/git/git $ time git blame -C builtin/blame.c > /dev/null
real 0m0.532s
user 0m0.502s
sys 0m0.030s
github/git/git $ time git blame builtin/commit.c > /dev/null
real 0m0.427s
user 0m0.417s
sys 0m0.010s
github/git/git $ time git blame -C builtin/commit.c > /dev/null
real 0m0.896s
user 0m0.896s
sys 0m0.000s
github/chromium/chromium $ time git blame chrome/browser/browser_about_handler.cc > /dev/null
Blaming lines: 100% (75/75), done.
real 0m23.355s
user 0m22.685s
sys 0m0.670s
github/chromium/chromium $ time git blame -C chrome/browser/browser_about_handler.cc > /dev/null
Blaming lines: 100% (75/75), done.
real 0m29.307s
user 0m28.766s
sys 0m0.541s
It is a bit, but not close to what I expected. Will merge this and make some more changes.
This applies the
-C
option to the git blame command which helps to better assign blame in files that've been moved around or otherwise reorganized. Instead of blaming the one who moved the code, we should continuing blaming the original committer for greater detail on the line of code rather than the reorganization history of the code.From the docs: