Scoped Git Changes

A small VS Code extension that shows only the Git changes for the folder you currently have open — built for monorepos and multi-project repos, where opening one project makes the built-in Source Control view list changes for the entire repository. In a multi-root workspace, every workspace folder gets its own scoped section (see Multi-root workspaces).

What it does

Open E:\projects\projectB (a subfolder of a single Git repo at E:\projects). VS Code's built-in Git view shows changes from projectA, projectB, and everything else. This extension adds a separate "Scoped Git" section in Source Control that lists only the changes under your open workspace folder, with:

• Working-tree and Staged change groups
• Open changes (diff) per file, scoped to the right side (HEAD ↔ Staged ↔ Working)
• Stage / unstage single files, or stage/unstage everything in scope
• Commit staged changes from the message box (Ctrl+Enter)
• Fetch / Pull / Push from the section's ... menu (or the command palette); the action button also shows a Sync Changes ↑N ↓M shortcut when the branch has diverged from its upstream
• Jump between changed blocks of the open file with F7 / Shift+F7 (next / previous hunk, wraps around)
• AI-generated commit messages (DashScope / any OpenAI-compatible endpoint)
• Commit history for your scope — recent commits that touched your open folder, expandable to the files each commit changed, with per-file diffs; unpushed commits are tinted and remote branch positions are marked (e.g. origin/main); multi-select commits to revert / undo them or copy their ID, message, file list, or diff
• Gutter (inline) diffs against the staged version

How "scoped" works

The extension finds the repository root by walking up from your workspace folder, then runs:

git status --porcelain -- <your-open-folder>

So you only ever see changes inside the open folder. All other operations (add, reset, commit) use the same scope pathspec where it matters.

Build & run (development)

Requirements: Node.js and the git CLI on your PATH.

npm install
npm run compile     # or: npm run watch

Debug in VS Code: open this folder and press F5 ("Run Extension" launches an Extension Development Host with the extension loaded, targeting a subfolder of any git repo you open there).

Install (one command)

The included deploy script (scripts/install-local.mjs) builds, packages and installs into your local VS Code in one step:

npm run deploy                                # installs into `code`
npm run deploy -- code-insiders               # …or code-insiders
CODE_CMD="C:\Program Files\Microsoft VS Code\Code.exe" npm run deploy   # full path also works

It cleans any old .vsix, runs @vscode/vsce package (which compiles first), then code --install-extension --force. Reload the window afterward: Ctrl+Shift+P → "Developer: Reload Window".

If you prefer the manual steps:

npm run package                               # produces scoped-git-changes-0.0.1.vsix
code --install-extension scoped-git-changes-0.0.1.vsix --force

Usage

1. Open a subfolder of a Git repo in VS Code.
2. Open the Source Control view — a Scoped Git section appears.
3. Hover a file for the quick icons (Open File / Stage / Unstage), or right-click for the full menu.
4. Write a message and press Ctrl+Enter (or the ✓ in the title bar) to commit the staged changes.

You can keep the built-in Git view enabled alongside this one, or disable the built-in Git extension if you want only the scoped view.

Fetch / Pull / Push

The … menu in the Scoped Git title bar — and the command palette — offer standalone Fetch, Pull and Push commands:

• Fetch — git fetch from the default remote; refreshes the remote branch markers in the history view without touching your working tree.
• Pull — git pull --rebase (the same strategy the sync action uses) and reports how many commits landed. Refused on a detached HEAD.
• Push — git push to the upstream branch; skips the round-trip when the branch is already in sync. A branch without an upstream triggers a prompt to publish it to origin (git push -u origin HEAD).

When there is nothing to commit and the branch is ahead/behind its upstream, the action button itself turns into Sync Changes ↑N ↓M (pull, then push, in one step).

Navigate changes in the open file

With a modified file open in the editor, press F7 / Shift+F7 (commands Scoped Git: Go to Next/Previous Change, also in the command palette) to jump between the file's changed blocks:

• Both staged and unstaged edits count (the diff is taken against HEAD); an untracked file counts as one block.
• The cursor decides where you are: next jumps to the first block starting below the cursor, previous first returns to the start of the block you're inside, then walks backwards. Both wrap around at the file ends, and the status bar briefly shows i/N.
• Pure deletions jump to the boundary line where the content was removed.
• The keybindings only apply in regular editors — inside a diff editor, F7 keeps its built-in "next difference" behavior. Rebind via Preferences: Open Keyboard Shortcuts → search "Scoped Git" if you prefer other keys.

AI commit messages

Click the ✦ (sparkle) icon in the Scoped Git title bar — or run Scoped Git: Generate Commit Message (AI) from the command palette / the commit button's dropdown — to generate a Conventional-Commits style Chinese commit message and place it in the message box. You still review and commit manually.

The message is generated from the staged diff of your open folder; when nothing is staged, the working-tree diff is used instead (untracked files are appended as a name list). Diffs larger than scopedGit.ai.maxDiffKB are truncated.

API key: read from the system environment variable DASHSCOPE_API_KEY — it is not stored in VS Code settings. If the variable is missing, you'll be prompted to paste the key on the spot (valid for the current VS Code session only). To make it permanent, set the system environment variable and restart VS Code:

:: Windows (restart VS Code afterwards)
setx DASHSCOPE_API_KEY sk-xxxx

# macOS / Linux — add to ~/.bashrc or ~/.zshrc, then restart VS Code
export DASHSCOPE_API_KEY=sk-xxxx

Commit history (scope)

Below the Scoped Git section in the Source Control sidebar you'll find Commit History (Scope) — the most recent commits that touched your open folder (like git log -- <your-open-folder>). Expand a commit to see the files it changed within your scope (with M/A/D status icons); click a file to open its diff for that commit (hash^ ↔ hash). The view refreshes automatically when HEAD moves (commits, amends, syncs, branch switches — including git operations from a terminal) or when remote-tracking refs move (fetch / pull / push), and has a manual refresh button in its title bar.

Local vs. remote at a glance: commits not yet pushed to any remote are tinted (color customizable via scopedGit.localCommitForeground), and commits that a remote-tracking branch points at are marked at the left of the row — a cloud icon in place of the commit dot plus the branch name (e.g. origin/main) shown before the commit message — so you can see exactly where the remote branch is. Everything above that marker is local-only; hover a commit for details. With no remote configured, nothing is tinted.

Commits support multi-select (Ctrl/Shift+Click). The context menu offers:

• Copy Commit ID / Message / Changed Files / Diff — copies the full hash(es), complete message(s), name-status file list (in scope), or patch content (in scope). Multiple selection concatenates.
• Revert Commit — creates one revert commit per selected commit, undoing each one's changes within the current scope only (files outside your folder are never touched). Reverts apply newest-first, like git revert. Refuses to run while you have staged changes in scope (commit or unstage them first), so revert commits stay clean.
• Undo Commit — soft-resets the branch (git reset --soft): rewrites history but keeps all changes staged. Only available when the selection is exactly the newest N commit(s) of the current branch; use Revert for anything older. Undoing everything back through the root commit leaves an unborn branch with the changes still staged.

Multi-root workspaces

Every workspace folder that sits inside a Git repo gets its own Scoped Git – <folder> section in Source Control — including several folders from the same monorepo, each scoped to itself. Stage / commit / push from a section only ever touches that section's scope. Folders added to or removed from the window while it's open are picked up on the fly; folders outside any Git repo are ignored.

Commit History (Scope) mirrors that layout: with several folders it shows one expandable section per workspace folder (labeled with the folder name), each listing the commits that touched its scope — a single folder keeps the classic flat list. Expanding a commit, opening a commit diff and all commit context-menu actions always act on the repo the node was listed from, even if the workspace changed afterwards. Command-palette commands and F7 act on the folder of the file you're editing; menu items, title-bar buttons and the commit box always act on the section they came from, no matter where the cursor is.

Notes & limitations

• Commit runs a standard git commit -m <msg> on staged changes. Because you stage from this view (which only lists your folder), normally only your folder's files are staged and committed — but any files you staged elsewhere in the repo are also committed (standard Git behavior).
• Filenames are decoded via Git's --porcelain v1 quoting; very unusual names may not parse perfectly.
• Rename/delete diffs are basic (versions of the new/old path).
• In the history view, merge commits list no per-file changes (Git emits none without -m); they show a placeholder instead, and Revert skips them.
• The history view reflects the current branch's HEAD only.
• Undo rewrites history — if the undone commits were already pushed, you'll need a force-push afterwards.