Open deadmeu opened 7 months ago
As you've mentioned extensions in first part: have you tried GitLens extension? I think it supports feature you are looking for and many other.
As you've mentioned extensions in first part: have you tried GitLens extension? I think it supports feature you are looking for and many other.
Yes I have. GitLens does have the exact features I'm describing but it also includes many others which I don't want or need. Many of these features get in the way of my editor and I don't think its reasonable to expect users to have to install a large extension like this one (and go through a lengthy configuration process to disable what they don't need) for simple inline blame annotations.
I also don't like how GitKraken advertises their commercial services to users. For example, I have a GitKraken Pro (Trial)
message in my status bar, which I can't seem to disable. Additionally, I have received notifications in VS Code from the GitLens extension advertising its subscription services to me, which I don't think is necessary.
The popularity of GitLens and similar extensions has shown that users really value solid git integration within their editor, so I think it makes sense to integrate inline git blame annotations natively into VS Code. Other git enhancements, like https://github.com/microsoft/vscode/issues/179053, https://github.com/microsoft/vscode/issues/191693, and https://github.com/microsoft/vscode/issues/203873, would also be great to see, but this issue is specifically focused on inline blame annotations.
It might be worth including that this is a popular idea amongst other editors as well. For example, here's a feature request for this feature to be included in the newly released Zed editor https://github.com/zed-industries/zed/issues/4793.
I found GitLens far too intrusive, but I've really liked the simple Git Blame extension. It shows the blame information in the status bar, rather than inline, which differs from OP's request but I personally find this preferable since it's available at-a-glance but not constantly in the way of my coding.
i don't like gitlens/kraken intrusiveness of their commercial offerings either, i switched to Git Blame months ago too, but it was only TODAY i learned that you can turn on inline blames 🤦♂️
this should be more prominent on the extension docs
even though something native will probably be more efficient, this will do for me
@lszomoru Dupe of https://github.com/microsoft/vscode/issues/203841 ?
No. https://github.com/microsoft/vscode/issues/203841 is git blame for the whole file that is being shown in the gutter.
Zed editor already has native support for git blame now https://github.com/zed-industries/zed/pull/10398, when are we going to get it natively in vscode ?
As everyone has told, Git Lense is really intrusive, even switching off pro feature, still they try to advertise their pro feature like the git graph. 100s of settings on each feature makes it really hard to get some simple thing done related to git. Recently I got rid of git lens and started to use default vscode support for day to day git operation which proves to be more efficient. what is missing is full repo log view (currently using Git Graph extension) and Git Blame, which doesn't have a very good alternative in market place.
One of the first things I (and I presume many other developers) do when installing a new text editor or IDE is to enable inline git blame annotations (either natively, if the editor supports it, or via an extension).
Inline git blame annotations make it extremely easy to see when a particular line was last modified without requiring the user to perform clicks in order to get that information.
Additionally, the user should be able to interact with this annotation by hovering the cursor over the text, in order to quickly get a more detailed view of the commit.
I think it makes sense to include this feature as a native feature within VS Code, rather than relying on third-party extensions, as VS Code already includes native git tooling and this highly popular feature builds upon existing features to provide a great QOL improvement and make it easier for developers (both new and old) to work with git.