IntelliG for VS Code

IntelliJ IDEA-style Git integration for Visual Studio Code. Brings familiar Git workflows — changelists, commit dialog, branch popup, interactive rebase, shelf, blame annotations, merge resolution, and more — right into VS Code.

Features

Commits & Changelists

• Commit Dialog — structured commit workflow with sign-off, custom author, recent-message history, and issue-link shortcuts
• Commit Tool Window (opt-in) — dedicated SCM view with Local Changes + combined Shelf/Stash tab
• Changelists — organize pending changes into named lists with descriptions and an active-list indicator
• Revert & Drop Selected Changes — deselect individual files before reverting or dropping

Branches, Tags & Log

• Branch Popup — sectioned, searchable popup with Recent, Favorites, and contextual action menus
• Branch Tree Provider — local, remote, and tag groups with right-click context menus
• Favorites — star branches for quick access
• New Branch / New Tag dialogs — with validation and remote-start-point detection
• Log with Graph — commit-history viewer with graph visualization, filtering, jump-to-hash, and cherry-pick highlighting
• File History — --follow file history with branch filter, diff-any-two, and compare-with-local
• Branch Comparison — compare any branch with the current branch or the working tree

Push, Pull & Fetch

• Push Dialog — force-with-lease as the default safe force, protected-branch guard, multi-repo
• Pull Dialog — --rebase / --ff-only / --autostash flags with automatic conflict handoff
• Push All Tags
• Auto Fetch — configurable scheduler with fetch.tags auto-sync and an incoming-commits status-bar badge

Merge, Rebase & Cherry-pick

• Interactive Rebase — reorder, squash, fixup, edit, reword, and skip commits visually
• Merge Dialog — strategy flags (--ff-only, --no-ff, --squash) with conflict handoff
• Three-way Merge View — accept current / incoming / both, plus apply-all-non-conflicting left/right
• Cherry-pick Variants — standard, without-commit, apply-selected-changes, and apply-files-to-branch

Shelf, Stash & Patches

• Shelf — shelve and unshelve changes, with silent variants, rename, and import-patches
• Stash Context Menu — branch-from-stash, rename, drop
• Apply Patch — create a patch from local changes or apply any .patch / .diff

Blame & Annotations

• Inline + Gutter Blame — configurable annotation style (inline / gutter / both / off)
• Blame Options — Ignore Whitespace, Detect Movements Within File / Across Files, Annotate Previous Revision

Integrations

• Git Tool Window (tabbed) (opt-in) — Log, History, Update Info, Incoming, Console tabs
• Explorer & Editor Context Menus — stage, unstage, revert, diff, show history, open on remote
• External Hosting Links — open commit / compare / branch pages on GitHub, GitLab, or Bitbucket
• Status Bar — current branch + incoming/outgoing commit badge
• IntelliJ Keymap Preset — optional set of IntelliJ IDEA-style keyboard shortcuts

Multi-repo support

IntelliG discovers Git repositories in three layered ways and surfaces them all together — single-repo workspaces, multi-root workspaces, and folders that contain nested repos all "just work."

• One workspace folder, one repo. The most common case. The folder itself is treated as a repository if it contains a .git directory.
• Multi-root workspace. Each top-level workspace folder is scanned for a repo. All discovered repos appear together in the branch popup, status bar, and tool windows.
• Nested-repo discovery. If a workspace folder contains nested repos (for example, a ~/work/ folder that holds ~/work/projectA/.git and ~/work/projectB/.git), both are discovered up to the configured scan depth.
• Mid-session new-repo detection. Running git init newproject/ inside a workspace folder is auto-detected — the new repository is picked up without a reload.

Scan-depth and ignore configuration

Two settings control how deep IntelliG looks for nested repos. Defaults and full descriptions live in the Configuration reference → Multi-repo discovery table below; the short version:

• intellig.repositoryScanMaxDepth — how many directory levels below each workspace folder are scanned for .git directories. Default 1 (workspace folder itself + immediate children); -1 for unlimited depth (uses a realpath cycle guard so symlink loops are safe). Mirrors VS Code's git.repositoryScanMaxDepth.
• intellig.repositoryScanIgnoredFolders — extra folder basenames you want to skip during the scan. User-extensible.

The following folder basenames are always excluded from the nested-repo scan and cannot be overridden: .git, node_modules, .vscode, out, dist, .next, target, build, vendor. These are hard-coded to keep the scan fast on real-world projects.

Submodule init mid-session is loaded as a separate top-level repo (intentional — matches VS Code's built-in git extension behaviour).

Diagnostics: Output → IntelliG

IntelliG writes init failures, watcher errors, and per-file operation diagnostics to a dedicated Output channel called IntelliG.

• Open via VS Code's Output panel (View → Output), then pick IntelliG from the channel dropdown.
• Init / watcher errors are surfaced here without flooding the notification toast area.
• Operations that batch over many files — for example Import Patches into Shelf — write a sanitized line per failed file so you can spot the bad one without re-running.
• All output is sanitized: credentialed URLs and home-directory paths are redacted before being written.

If the IntelliG output channel is missing, the extension didn't finish activating. Reload the window and check the channel again.

Structured-record format

Each diagnostic is written as a structured record — one block per event — so you can scan, grep, and copy entries reliably. The first line always follows this shape:

[<timestamp>] <LEVEL> <component>: <message>

• <timestamp> is an ISO-8601 instant (e.g. 2026-05-12T14:03:11.482Z).
• <LEVEL> is the record's severity, uppercased and padded to five characters (TRACE, DEBUG, INFO , WARN , ERROR).
• <component> names the subsystem that emitted the record.
• <message> is the sanitized message; embedded newlines are escaped to a literal \n so each record stays on one parseable line.

When present, the following detail lines follow the header, each indented two spaces:

• ctx=<json> — structured context for the event, as a single-line JSON object.
• cid=<correlationId> — correlates every record emitted while handling the same command invocation.
• err=<message> — the error message, followed by its stack trace with each frame on its own indented line.

Controlling log output

Two settings tune what reaches the channel:

• intellig.log.level — the minimum severity admitted to the logger (trace, debug, info, warn, error, or off; default info). Records below the threshold are dropped before they're built, and off silences the logger entirely. Changes apply to subsequent records without a reload.
• intellig.log.console — when true, mirror each record to the developer console as well as the channel (default false). The console output is visible only in the Extension Development Host, so this is aimed at contributors debugging IntelliG itself.

Coexistence with VS Code's built-in Git

IntelliG runs git directly via child_process rather than going through VS Code's git extension API. The practical implications:

• IntelliG works even when git.enabled is set to false.
• IntelliG does not register a Source Control panel — VS Code's built-in SCM view continues to work alongside IntelliG's IntelliJ-style panels (Branch popup, Git tool window, etc.).
• File-tree decorations (M / U / A glyphs in the Explorer) come from VS Code's built-in git extension. IntelliG does not double-paint decorations.
• You can disable VS Code's built-in git decorations and still have IntelliG's tool windows fully functional.
• Both extensions write to the same .git/index file. Git serializes concurrent writes via .git/index.lock; if you trigger stage / commit / amend operations in both extensions in the same instant, you may briefly see an "index locked" toast. This is harmless — retry the operation and it will succeed.

Known limitations

• Submodule init mid-session — auto-loaded as a separate top-level repo (intentional, matches VS Code's git extension).
• One-shot rm -rf .git/ may not auto-detect — when the entire .git/ directory is removed in a single syscall (rm -rf .git), VS Code's FileSystemWatcher does not always deliver a child-path delete event, so the repo may stay in IntelliG's view until you reload the window. As a workaround, deleting .git/HEAD first (rm .git/HEAD) reliably triggers the removal event. The repo is fully removed if you drag its workspace folder out of VS Code, or on the next window reload.

Requirements

• VS Code 1.85+
• Git installed and available on PATH

Keyboard Shortcuts

Heads up — Ctrl/Cmd+Alt+Z collision under IntelliJ preset. Both intellig.unstageSelected (default keymap) and intellig.revertFile (IntelliJ preset) bind to Ctrl/Cmd+Alt+Z, and the IntelliJ-preset binding is more specific so it wins. If the IntelliJ preset is enabled, this chord performs a revert on disk (a destructive operation) — not unstage. To unstage while the preset is on, right-click the file in Local Changes → "Unstage" or run IntelliG: Unstage Selected Files from the command palette.

Merge view (active when the IntelliG merge tab is focused)

These bindings are scoped to activeWebviewPanelId == 'intellig.mergeView', so they don't collide with anything outside the merge view.

How to read this table

The Default column lists the binding active out of the box (no preset). The IntelliJ Preset column lists the binding active when the preset is on. When the same chord appears in both columns, it's the same command under either mode. An em-dash (—) means the action has no chord under that mode; use the command palette (Ctrl/Cmd+Shift+P → IntelliG: <action>) to invoke it.

Enable the IntelliJ preset in settings:

"intellig.keymapPreset": "intellij"

Configuration reference

Opt-in feature flags

Multi-repo discovery

Commit & Push behavior

Fetch & shelf

Blame annotations

UI polish

Logging

Feedback & Issues

Found a bug, have a question, or want to request a feature? Open an issue on the public issue tracker.

For security vulnerabilities, please use GitHub's private vulnerability reporting — your report stays private to repo maintainers and isn't disclosed publicly until a fix ships.

License

Proprietary — all rights reserved. The full LICENSE file is included in the extension package. For licensing inquiries, open an issue tagged licensing.