Sertion / vscode-gitblame

Visual Studio Code Extension - See Git Blame info in status bar.
https://marketplace.visualstudio.com/items/waderyan.gitblame
MIT License
72 stars 31 forks source link

Button not working #129

Closed jgillard closed 1 year ago

jgillard commented 1 year ago

This has been the case for a while (at least a month I'd think) so I'm now deciding to report this. When I press the button in the bottom bar, it flashes briefly (too briefly for me to read what it says), and then it returns to its normal message of name & date.

Here's what's logged in the Git Blame Output:

[ 15:07:53 | command ] /opt/homebrew/bin/git ls-remote --get-url origin
[ 15:07:53 | command ] /opt/homebrew/bin/git symbolic-ref -q --short HEAD
[ 15:07:53 | command ] /opt/homebrew/bin/git config branch.master.remote
[ 15:07:53 | command ] /opt/homebrew/bin/git config remote.origin.url
[ 15:07:53 | command ] /opt/homebrew/bin/git ls-files --full-name -- /Users/james/journee-git/journee-form-response-interface/src/common.py

I'm running VS Code 1.69.2 on MacOS 12.5, and v9.0.0 of Git Blame, so all the latest versions. I have no custom settings for this extension. What else can I do to help track down the issue here?

Sertion commented 1 year ago

Hey James. Thank you for the bug report!

This is indeed unexpected behavior. I've been able to sort of recreate it by setting gitblame.infoMessageFormat to an empty value. However if you have made no changes to any settings I have no idea what is wrong.

If possible I would love to see what the output from the commands in the output you have posted is. Especially git config remote.origin.url.

jgillard commented 1 year ago
> git ls-remote --get-url origin
git@gitlab.com:journee/form-response-interface.git
> git symbolic-ref -q --short HEAD
master
> git config branch.master.remote
origin
> git config remote.origin.url
git@gitlab.com:journee/form-response-interface.git
> git ls-files --full-name -- /Users/james/journee-git/journee-form-response-interface/src/common.py
src/common.py
Sertion commented 1 year ago

Thank you very much for the quick response.

I've found some minor issue with 9.0.0 and have uploaded a new patch release (9.0.1). It should be available soon. I don't think it necessarily will fix this issue but I would love it if you tried it and got back to me with the results.

jgillard commented 1 year ago

I uninstalled 9.0.0 to install 9.0.1, and I'm still seeing the same behaviour as before.

Sertion commented 1 year ago

I have kept looking at it for a while now and could it be that the git commit summary for the blamed commit is empty?

If it is. What would be the expected behaviour if the info message would be empty?

jgillard commented 1 year ago

By git commit summary do you mean subject? I can rule that out as the cause, we don't have empty ones of those.

I feel a bit useless in this process. Is there a debug level of logging I can access somehow so that I can dig in myself? I've not debugged a VS Code extension before.

Sertion commented 1 year ago

You have been very helpful so far. Summary is what git calls the subject in the porcelain output format.

There is no debug mode or anything like that.

What is hard with this extension in particular is that it interacts with both vscode and git. vscode can have different settings by workspace, user account, or globally and different git repositories have a near infinite variety.

The commands you provided earlier told me that you don't do anything weird like having multiple remotes or run an uncommon/custom git hosting service setup.

The behaviour you describe is weird for two main reasons:

  1. It appears to only be able to occur when there is no commit information for a line. (source)
  2. It is only possible to click the status bar element when there is commit information available for a line. (source)

At the surface these two statements contradict each other.

You said that the message goes back to the default "Name (time ago)" format afterwards and when I checked it is possible for message in showMessage to evaluate to an empty string that will not be shown in the info box when sent to infoMessage.

With that possibility ruled out thanks you your very appreciated helpfulness I am out of ideas. What I have left, sadly, are more questions:

  1. Is the bug consistent across multiple files and repositories?
  2. Are you certain that the repository isn't overriding any settings?
  3. Does the info message notification display if you set gitblame.infoMessageFormat to "test message" and click the status bar element?

I am sorry for the longer post. I felt I had lacked some context in earlier comments and have provided more. Your assistance so far has been invaluable and I hope what the issue can be resolved.

jgillard commented 1 year ago

You've been great so far! I mostly meant that I felt bad responding with not much more than "still doesn't work".

I cloned this project and got it running with the debugger. As I said earlier, I've got no experience with these extensions, so I've just had a poke around. The info from git all seems to look OK in this screenshot. But then the infoMessage (which I assume is the pop-up box in VS Code) never appears.

Screenshot 2022-08-02 at 18 45 16

I've also tried this setting, which opens the browser to the correct URL! So it seems to be just the VS Code popup box that has an issue.

"gitblame.statusBarMessageClickAction": "Open tool URL"

And to address your questions:

  1. Yes I have the same issue across all the project I've opened.
  2. I've used the settings UI to flick between User & Workspace and I think it's all defaults.
  3. The window doesn't open with just that string in the settings.
Sertion commented 1 year ago

This is incredible helpful! Good job in getting it up and running.

I perhaps should have asked this earlier, but I just remembered that they added this a while back; have you enabled do not disturb mode in vscode?

jgillard commented 1 year ago

It was that 😭 I didn't even know about that feature so not sure how it got enabled, but I've disabled it and the issue I reported is now working again. Thanks so much for the quick replies and patience! You've been a ⭐️

Sertion commented 1 year ago

It is always the easiest explanations that are the hardest to find. Thank you for your quick and accurate answers!

stephan281094 commented 11 months ago

Omg I just had the exact same issue 🤦‍♂️. Thank you, guys!