Git Blame Solo

Git Blame Solo answers "who changed this line, when, and why?" and shows how the code got there, without making you leave the editor.

Move your cursor to any line and a quiet annotation at the end of it shows the author, how long ago it changed, and the commit message. Hover the line to see the full commit and the exact change it introduced. One more click gives you every file in that commit with colored diffs, and you can revert a single hunk from there if you need to.

For the bigger picture, the git log shows the repository's commits with a branch graph, and a file's history lists every commit that changed it. The Worktrees view creates, opens, and cleans up git worktrees, so you can work on several branches side by side. It stays out of the way and has no dependencies beyond the git you already have installed.

Table of contents

• Features
  • Inline blame on the current line
  • File blame
  • Uncommitted changes, even before you save
  • Rich hover: the commit and what it changed
  • Native diff editor
  • Commit details panel
  • Git log and file history
  • Author history
  • Previous versions of a file
  • Compare branches, tags, and commits
  • Line history
  • Step back through a line's history
  • Revert a single hunk
  • Worktrees
  • Commands
• Requirements
• Installation
• Settings
• Known limitations
• Development
• Contributing
• License

Features

Inline blame on the current line

As your cursor moves, a faded annotation appears at the end of the active line:

Jane Doe, 3 days ago • Fix race condition in session refresh

• Only the active line is annotated, so the rest of your code stays uncluttered. To see every line's blame at once, turn on file blame.
• Recomputation is debounced (150 ms by default), so scrolling or holding an arrow key doesn't spawn a flood of git processes.
• The whole file is blamed once per document and cached, so moving between lines never runs git again. Edits shift the cached result instead of discarding it, and the file is blamed again once you pause typing or save.
• The format is fully customizable through a template. See gitBlameSolo.decorationTemplate.
• Your own commits read as "You" instead of your name.
• Dates follow your region's conventions: vor 3 Tagen, 3 gün önce, 22.09.2026, 14:39. By default they follow your operating system's region settings; set gitBlameSolo.dateLocale to vscode for VS Code's display language, or to a tag such as en-GB. The iso date style shows 2026-09-22 14:39 everywhere.
• Prefer the status bar? Turn on gitBlameSolo.statusBar.enabled, and optionally turn off gitBlameSolo.enabled.
• Turn on gitBlameSolo.renderEmoji to show shortcodes such as :sparkles: and :bug: in commit messages as the gitmoji they stand for: ✨ and 🐛, in the annotation, hover, git log, and commit details.
• Turn on gitBlameSolo.highlightCommitLines to highlight every other line of the file from the same commit as the current line, with marks in the scroll bar, so you see the whole change at a glance. The colors are the gitBlameSolo.commitLinesBackground and gitBlameSolo.commitLinesOverviewRuler theme colors.
• Commits listed in a .git-blame-ignore-revs file at the repository root, such as bulk reformatting, are skipped automatically, as GitHub does.

With gitBlameSolo.highlightCommitLines on, moving between lines shows which other lines each commit changed:

File blame

Turn on gitBlameSolo.fileBlame.enabled, or run Git Blame Solo: Toggle File Blame (also a button in the editor title bar), to show blame for every line of the file in a column before the text:

Jane Doe, 3 days ago    export function refresh() {
                          const session = load();
John Roe, 2 years ago     if (!session) {

• Only the first line of each block of lines from the same commit is labelled, so the blocks stand out. The column is formatted with gitBlameSolo.fileBlame.template and cut at 50 characters.
• A heatmap tints the column by how recent each line's commit is among the file's commits, from blue for the oldest to orange for the newest and uncommitted lines. Turn it off with gitBlameSolo.fileBlame.heatmap.
• Hovering the column shows the same hover as the inline annotation, for any line.
• It uses the same cached whole-file blame as the inline annotation, so it runs no extra git commands.

File blame is off by default.

Uncommitted changes, even before you save

When a line hasn't been committed yet, the annotation says "Uncommitted changes". Git keeps no time for uncommitted lines, so the annotation adds when the file was last saved (file saved 3 days ago), or (file not saved) while the file has unsaved changes.

Blame is computed against the live editor buffer: the extension pipes the buffer's contents to git blame --contents -. Lines you just typed are flagged correctly before you save, and line numbers never drift out of sync with what's on disk.

While you type, edited lines read as uncommitted right away without running git. About a second after you stop typing, the buffer is blamed again, so a line you changed back to its committed text shows its commit again without saving.

Hovering an uncommitted line shows how many lines changed since the last commit, unsaved edits included. Show change inline opens VS Code's change peek at that line, with the committed lines above your version, and Open in Diff Editor compares the whole file with its last commit.

Rich hover: the commit and what it changed

Hover the inline annotation at the end of the current line to open a popup containing:

This shows you the context of a change right away: you see the rest of the block that changed with the line, not just the one line in isolation.

By default the popup only opens over the annotation, so hovering your code for other tooltips (types, errors, docs) isn't crowded by blame. To get it anywhere on any line instead, set gitBlameSolo.hover.trigger to "line".

Show change inline opens the same block right under the line, in a peek like VS Code's own for local changes: removed lines on red and added lines on green, with their line numbers before and after the commit, highlighted as the file's language. The list beside it holds the line's history, newest first: each commit that changed the line, with its author and date. Pick one to see its change to the line in the same place, or double-click a change to open that commit's diff of the file.

Native diff editor

Open in Diff Editor in the hover opens the file in VS Code's built-in side-by-side diff editor, comparing the commit (<sha>) against its parent (<sha>^). Syntax highlighting, inline/side-by-side toggling, and navigating between changes all work as usual.

Commit details panel

View changed files in the hover (or the Git Blame Solo: Show Commit Details command) opens a panel with the whole commit:

• The commit message, author, co-authors, date, and hash at the top. The button next to the hash copies it.
• Every file the commit touched, each with its full colored diff. Added and removed lines are clearly marked.
• Click a file header to open that file in the editor. The arrow at its start folds or unfolds the file's diff, and Collapse all / Expand all fold every file at once.
• The Open Diff button opens that file's change in the native diff editor.
• The line you started from is highlighted inside its file's diff, so you don't lose your place in a large commit. Clicking the highlighted line takes you back to that spot in the editor.
• The file you came from is marked with a colored border and an "Opened from this file" badge, and the panel scrolls to it. The commit's other files start folded, so that file stands out. This works from the blame hover and from a file's history, even if the file had another name in that commit.

Git log and file history

Git Blame Solo: Show Git Log (also the commit icon in the Source Control view's title bar) opens a panel listing the repository's commits, newest first, with a commit graph showing how branches split and merge. Branches, remote branches, and tags are shown as badges on their commits, and the checked-out branch is highlighted.

• Pick which history to show: the current branch, all branches (including remote branches and tags), or any single local or remote branch.
• Search commit messages and filter by author (name or email). Both match the text as typed, ignoring case. Click an author in the list to show only their commits.
• File history: Git Blame Solo: Show File History (the history icon in the editor title bar, or the right-click menu of a file in the Explorer, an editor tab, or the Source Control view) shows only the commits that changed that file, following renames. Clear the file chip in the toolbar to see every commit again. A commit opened from a file's history marks that file in the commit details panel.
• Click a commit (or press Enter on it) to open the commit details panel with its diffs. The button next to the hash copies it. Use the arrow keys to move between commits.
• With gitBlameSolo.showUnpushed on, commits on the current branch that no remote branch contains yet get a not pushed badge.
• Commits load 200 at a time; Load more fetches the next page.

The graph is hidden while a search, author, or file filter is on, because the filtered list leaves out the commits the lines would pass through.

Opening a commit from a file's history takes you straight to that file in the commit details panel, with the commit's other files folded:

Author history

Git Blame Solo: Show Author History, or a click on the author in the blame hover, opens the git log of every branch filtered to that author's commits. In the git log, clicking an author's name does the same. The filter uses the author's email, so every spelling of their name is included.

Previous versions of a file

In a file's history, hover a commit for two more buttons:

• Open opens the file as it was in that commit, read-only, with blame and the hover working there too.
• Compare opens that version in the diff editor against your working copy.

Both follow renames, so a commit from before the file was renamed opens under its old name. Git Blame Solo: Open File at Revision… and Compare with Revision… do the same from a list of the file's commits; they are in the editor title bar's … menu and the right-click menus of files in the Explorer and editor tabs.

Compare branches, tags, and commits

Git Blame Solo: Compare Branches, Tags, or Commits… (also the compare button in the Source Control view's title bar) compares two branches, tags, or commits, or one of them with your working copy:

• Pick each side from your branches, remote branches, and tags, or type a commit hash or an expression such as HEAD~3.
• Every file that differs opens in one multi-diff editor, with renames detected.
• In the git log, Compare… on a commit starts the comparison from that commit.
• Compare File Between Revisions… diffs one file between two of the commits that changed it.

Line history

Line history in the hover (or the Git Blame Solo: Show Line History command) lists every commit that changed the current line, newest first, using git log -L. The line is followed across edits and renames, and the list works for unsaved edits and past revisions too.

Type to filter by message, author, or hash. Pick a commit to open its change to the file in the diff editor, at the line. The buttons on each entry open the commit details panel or copy the commit hash. The list shows up to 100 commits.

Step back through a line's history

Blame previous revision in the hover (or the Git Blame Solo: Blame Previous Revision command) opens the file as it was just before the commit that last changed the line, side by side with its current version in the diff editor, with the cursor on the matching line on both sides. The past revision on the left has inline blame and the hover too, so you can keep stepping back to see who wrote the line before, and why, until you reach the commit that created it. Each step still compares with the current file, and renames are followed along the way.

Revert a single hunk

Each hunk in the panel has a Revert Hunk button. It undoes only that hunk in your working copy using git apply --reverse and leaves the rest of the commit alone.

Several safeguards are built in:

1. Unsaved changes block the revert. If the file has unsaved edits, you're asked to save or discard them first.
2. Always asks first. A modal dialog shows exactly which lines will be affected before anything changes.
3. Fails safely. If the file has changed since that commit and the hunk no longer applies cleanly, the file is left untouched and you get a clear error message.

After a successful revert, the button changes to Reverted, and a notification offers to open the file.

Worktrees

The Worktrees view, opened from its icon in the Activity Bar, lists every worktree of the open repositories: the main one first, then each linked worktree with its branch, folder, and whether its branch is merged. A worktree checks out another branch in a folder of its own, so you can work on a hotfix or review a pull request without stashing or switching branches.

• Create Worktree… (the + button) checks out a new branch, an existing local branch, or a remote branch as a new local branch that tracks it. Branches already checked out in a worktree aren't offered.
• New worktrees go in gitBlameSolo.worktrees.folder when it is set. Otherwise they go in the folder the repository already uses, .worktrees/ inside it or <repo>.worktrees/ next to it; with neither, you're asked, with the folder next to the repository recommended. For .worktrees/, the extension offers to add it to .gitignore if git doesn't ignore it yet. The proposed folder is named after the branch (feature/login → feature-login), and you can change it before the worktree is created.
• Each worktree has buttons to open it in a new window or this one, reveal it in the file manager, copy its path, show its git log, and delete it.
• Each linked worktree's branch shows whether it is merged into the default branch (origin/HEAD, or the main worktree's branch without a remote) or how many commits it is ahead, and whether its upstream branch is gone, as after a merged pull request's branch was deleted.
• Delete works on one worktree, every selected one, or all of them with Clean Up Worktrees…. After you confirm (worktrees with uncommitted changes are marked, as those changes are lost), you pick which of their branches to delete too, with their merge status; pick none to keep them all. Deleting a branch that isn't merged asks again. If a picked branch tracks a branch on a remote, you're asked whether to delete it there too: Delete from Remote runs git push <remote> --delete, Local Only deletes it only here. The main worktree, the one open in this window, and locked worktrees are never deleted.
• When the window has a linked worktree open rather than the repository's main folder, a Worktree: item in the status bar says so, and with several workspace folders the worktree's folder gets a WT badge in the Explorer.

Commands

Open the Command Palette (Cmd/Ctrl+Shift+P) and type Git Blame Solo:

None of the commands has a default shortcut. To add one, open Keyboard Shortcuts (Cmd/Ctrl+K Cmd/Ctrl+S) and search for Git Blame Solo.

Requirements

• VS Code 1.90 or later.
• git available on your PATH. If it isn't, the extension shows a one-time warning and turns off blame and hover.
• The file must be inside a git repository. Files outside a repository are ignored.

Installation

Search for Git Blame Solo in the Extensions view, or run:

code --install-extension SeniorTurkmen.gitblamesolo

It is published to the Visual Studio Marketplace and to Open VSX.

Settings

Every setting below can also be changed from the Command Palette with Git Blame Solo: Change Setting…. It lists each setting with its current value; pick one to toggle it, choose from its values, or type a new one. The change applies right away:

For example, to show the short hash first with an absolute date:

{
  "gitBlameSolo.decorationTemplate": "${hash} · ${author} · ${date}",
  "gitBlameSolo.dateStyle": "absolute"
}

Known limitations

• The time shown for uncommitted lines is when the file was last saved, not when that line changed. While the file has unsaved changes, no time is shown.
• The remote URL and your user.email are re-read when the repository's config file or your global git config (~/.gitconfig, ~/.config/git/config, or $GIT_CONFIG_GLOBAL) changes. Changes elsewhere, such as the system config or a file pulled in with include, need Git Blame Solo: Refresh.
• Files larger than gitBlameSolo.maxFileSizeKB are skipped.
• Only local files and the past revisions this extension opens are blamed. Other virtual or remote file systems aren't.
• The Worktrees view reads the worktrees again when VS Code's git extension reports a change, when the window gets focus, and on Refresh Worktrees. A worktree added or removed in a terminal shows up once you switch back to VS Code or refresh.
• VS Code has no API to mark the window title or the Explorer's project name, so a linked worktree is shown in the status bar instead.

Development

Requires Node.js 22 or later.

npm install
npm run watch     # esbuild watch mode

Press F5 to launch the Run Extension configuration and try the extension in an Extension Development Host.

Project layout

src/
├── extension.ts        # activation, command registration
├── config.ts           # typed access to gitBlameSolo.* settings
├── git/                # thin wrappers around the git CLI + output parsers
├── cache/              # per-document / per-commit caches
├── decorations/        # end-of-line annotation
├── hover/              # hover provider
├── webview/            # commit details and git log panels
├── views/              # Worktrees view and the worktree status bar item
└── util/               # date formatting, diff rendering, commit graph layout

Testing

npm run typecheck   # full type-check via tsc --noEmit
npm run test:unit   # pure function tests (parsers, caches, date formatting)
npm test            # end-to-end integration tests in an Extension Development Host

Packaging

npx vsce package --no-dependencies   # builds dist/ via vscode:prepublish

Publishing

Publishing a GitHub release runs .github/workflows/publish.yml. The release tag must match the package.json version, for example v0.1.1. The workflow:

1. Packages the extension once into a .vsix.
2. Publishes that same package to the Visual Studio Marketplace and to Open VSX, in separate jobs, so a failure in one doesn't block the other.
3. Attaches the .vsix to the GitHub release.

To publish the current package.json version without a new release, or to retry a single store, run Publish from the Actions tab and pick both, marketplace, or openvsx.

Visual Studio Marketplace

The Marketplace job signs in to Microsoft Entra ID as a user-assigned managed identity, using the workflow's GitHub OIDC token, and publishes with vsce publish --azure-credential. No Marketplace token is stored, so the retirement of global Azure DevOps PATs doesn't affect it. One-time setup:

1. Managed identity. In the Azure portal, create a User Assigned Managed Identity in any subscription (a free one works). Note its Client ID, and the Tenant ID of your directory.
2. Federated credential. On the identity, open Settings → Federated credentials → Add credential, pick GitHub Actions deploying Azure resources, and enter organization SeniorTurkmen, repository gitblamesolo-extension, entity Environment, environment marketplace.
3. GitHub. In this repository's settings, create the environment marketplace, and add the Actions variables (not secrets) AZURE_CLIENT_ID and AZURE_TENANT_ID.
4. Member ID. Run Publish from the Actions tab with target marketplace-identity. The run summary shows the ID the Marketplace knows the identity by.
5. Publisher. On the Marketplace publisher management page, create the publisher SeniorTurkmen if it doesn't exist yet (the ID must match publisher in package.json). Under Members, add the ID from step 4 with the Contributor role.

After that, releases publish to the Marketplace automatically. To publish the current version on its own, run Publish with target marketplace.

Open VSX

The Open VSX job publishes with trusted publishing, so no access token is stored in the repo.

Creating the SeniorTurkmen namespace makes you a contributor, not an owner. The Trusted publishers page only lists namespaces you own, so it stays empty until ownership is granted.

Until then, publish with an access token:

1. Create a token at Access tokens.
2. Add it to this repo as the Actions secret OVSX_PAT. The workflow uses that secret when it is set.

After you claim the namespace and Eclipse grants it, the Trusted publishers page lists SeniorTurkmen. Add this repository there with workflow file publish.yml and no environment, then remove OVSX_PAT. Later releases publish with the workflow's OIDC token and no stored secret.

Contributing

Contributions are welcome! Bug reports, feature requests, and pull requests are all appreciated.

Before opening a PR, please make sure these all pass:

npm run typecheck
npm run lint
npm run test:unit

If you're changing anything under src/git/, src/cache/, or src/util/, add or update a unit test alongside it. Those modules are plain Node/TypeScript with no vscode dependency, so they run instantly under npm run test:unit. Anything under src/decorations/, src/hover/, src/views/, src/webview/, or src/extension.ts needs vscode and is covered by npm test (Extension Development Host) or manual testing via F5.

License

MIT