Closed MartijnHols closed 1 month ago
Hey Martijn. Thank you for the bug report!
I know it is unhelpful but: "it works on my machine(s)".
Do the commands fail silently or with an error message?
What version of vscode, git, and operating system do you use? Does the "Git Blame" output log contain anything?
Thanks for your quick response. I can certainly appreciate a good "it works on my machine" :)
Sorry, I was just in between things making this report so I didn't think about providing any helpful information. Here goes:
VSCode version: 1.89.1 Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685 Date: 2024-05-07T05:14:24.611Z (3 wks ago) git version 2.21.0 OS: MacOS Sonoma 14.5 (23F79)
I also tested a bunch of other repositories, including my personal website's, and they all seem to suffer from the issue. An example output line of git blame
on the CLI in case it helps: 88cb5f16 (Martijn Hols 2024-05-08 07:35:17 +0200 19) const Article = styled.article(
The commands all fail with a non-descriptive error:
It seems the report already has three thumbs up, so I'm guessing more people are experiencing the issue.
That repository works for me as well. I've done some digging and made some changes. I would appreciate it a lot if this pre-release(?) version could be tested:
Thanks. No difference
Actually, the command error is now Unable to blame current line. Unable to get blame information for line.
I'm also having a similar issue, with slightly different UI.
Version: 1.89.1 (Universal) Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685 Date: 2024-05-07T05:14:24.611Z Electron: 28.2.8 ElectronBuildId: 27744544 Chromium: 120.0.6099.291 Node.js: 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.5.0
git: 2.45.0 OSX 14.5 (23F79)
I can't figure out much of a pattern yet. It doesn't occur on every line of the file. The time seems to be from when I opened the file in vscode, not when changes were last made to the file. Also seems to be uncorrelated with commit author. Even a given commit is sometimes shows correctly in the blame and sometimes not.
Manually running git blame
or git blame -C
on the file seems to produce the expected results. It seems from logs that this extension uses git blame -C --incremental
. I'm not familiar with --incremental
but from what I can tell it is also outputting the right data.
I had a theory that the bug occurred when the lines output from --incremental
were out of order, but that doesn't seem to be the case once I tested enough.
Here's some of the recent output from the git blame extension:
2024-05-28 14:32:58.194 [info] /opt/homebrew/bin/git blame -C --incremental -- /Users/adam/code/monorepo/server/__tests__/modules/factoring/onboarding/factoring-onboarding-service.test.ts
2024-05-28 14:32:58.813 [info] Blamed "/Users/adam/code/monorepo/server/__tests__/modules/factoring/onboarding/factoring-onboarding-service.test.ts"
2024-05-28 14:34:10.991 [info] /opt/homebrew/bin/git ls-remote --get-url origin
2024-05-28 14:34:10.999 [info] /opt/homebrew/bin/git symbolic-ref -q --short HEAD
2024-05-28 14:34:11.006 [info] /opt/homebrew/bin/git config branch.adam/link_carrier_to_org_earlier.remote
2024-05-28 14:34:11.014 [info] /opt/homebrew/bin/git config remote.origin.url
2024-05-28 14:34:11.021 [info] /opt/homebrew/bin/git ls-files --full-name -- /Users/adam/code/monorepo/server/__tests__/modules/factoring/onboarding/factoring-onboarding-service.test.ts
2024-05-28 14:34:11.028 [info] /opt/homebrew/bin/git rev-parse --abbrev-ref origin/HEAD
2024-05-28 14:34:11.704 [info] /opt/homebrew/bin/git ls-remote --get-url origin
2024-05-28 14:34:11.713 [info] /opt/homebrew/bin/git symbolic-ref -q --short HEAD
2024-05-28 14:34:11.719 [info] /opt/homebrew/bin/git config branch.adam/link_carrier_to_org_earlier.remote
2024-05-28 14:34:11.726 [info] /opt/homebrew/bin/git config remote.origin.url
2024-05-28 14:34:11.733 [info] /opt/homebrew/bin/git ls-files --full-name -- /Users/adam/code/monorepo/server/__tests__/modules/factoring/onboarding/factoring-onboarding-service.test.ts
2024-05-28 14:34:11.740 [info] /opt/homebrew/bin/git rev-parse --abbrev-ref origin/HEAD
2024-05-28 14:37:00.152 [info] /opt/homebrew/bin/git ls-remote --get-url origin
2024-05-28 14:37:00.164 [info] /opt/homebrew/bin/git symbolic-ref -q --short HEAD
2024-05-28 14:37:00.170 [info] /opt/homebrew/bin/git config branch.adam/link_carrier_to_org_earlier.remote
2024-05-28 14:37:00.176 [info] /opt/homebrew/bin/git config remote.origin.url
2024-05-28 14:37:00.183 [info] /opt/homebrew/bin/git ls-files --full-name -- /Users/adam/code/monorepo/server/__tests__/modules/factoring/onboarding/factoring-onboarding-service.test.ts
2024-05-28 14:37:00.189 [info] /opt/homebrew/bin/git rev-parse --abbrev-ref origin/HEAD
Hey @amc6. Thanks for the added information. Have you tried the pre-release build mentioned above? The behaviour you report is how the bug I found in that one could have shown itself.
Have same issue with Git Blame v11.0.0 Git Blame v10.11.0 - work well
Output log for Git Blame
My /usr/local/git/etc/gitconfig
file
Hey @alexneo2003. Thanks for the addition!
A few questions:
git rev-parse --absolute-git-dir
in your terminal outside of vscode?Hey @alexneo2003. Thanks for the addition!
A few questions:
- Can you run
git rev-parse --absolute-git-dir
in your terminal outside of vscode?- Have you edited this file or is it the default content?
- Are you on a Mac?
fatal: Not a git repository (or any of the parent directories): .git
Hey @alexneo2003. Thanks for the addition! A few questions:
- Can you run
git rev-parse --absolute-git-dir
in your terminal outside of vscode?- Have you edited this file or is it the default content?
- Are you on a Mac?
1. `fatal: Not a git repository (or any of the parent directories): .git` 2. yes, I have edited that file (for no one file that I have edited blame not working) 3. yes, Mac
Thank you for the quick response. I was unclear. Could you please run git rev-parse --absolute-git-dir
in a folder with a git repository and have you edited /usr/local/git/etc/gitconfig
?
Thank you for the quick response. I was unclear. Could you please run
git rev-parse --absolute-git-dir
in a folder with a git repository and have you edited/usr/local/git/etc/gitconfig
?
/Users/*username*/Documents/projects/*project-name*/.git
Thank you for the quick response. I was unclear. Could you please run
git rev-parse --absolute-git-dir
in a folder with a git repository and have you edited/usr/local/git/etc/gitconfig
?1. `/Users/*username*/Documents/projects/*project-name*/.git` 2. by myself - no
What does type git
(or which git
if macs don't have type
) print in the same folder as you ran git rev-parse --absolute-git-dir
?
What does
type git
(orwhich git
if macs don't havetype
) print in the same folder as you rangit rev-parse --absolute-git-dir
?
git is /usr/local/bin/git
Thanks to the information provided I think I've found a second issue with the changes made in 11.0.0. Attached is a pre-release build. I would love it if someone who has the issue could try it and report back!
Thanks to the information provided I think I've found a second issue with the changes made in 11.0.0. Attached is a pre-release build. I would love it if someone who has the issue could try it and report back!
I have checked it and it works well
Thank you! 11.0.1-pre-release-2 has been linted, packaged and uploaded to the marketplace. I hope this will solve the issue for everyone in this thread (and those affected who has not participated)!
If issues still remain please open a new bug report. Thanks everyone for your patience and help!
Thanks for helping us! It's much appreciated (as well as the extension in the first place).
For anyone still running into the issue: I don't know if something was weird on my end, but I had to uninstall and reinstall the extension in order to get the update to actually fix the issue. No amount of extension restart and window reloading (via the command palette) applied the fix. Maybe restarting VSCode would have worked as well.
Thanks for the extension! It's exactly what I want. Unfortunately since 11.0.0, the blame is no longer working with the message "No info about the current line":
All commands also fail. This is in a file with 41 lines, and changing the
gitblame.maxLineCount
setting seem to make no difference. The extension works fine after downgrading to 10.11.0.