September 5, 2026 · Feature release
Git is now documented inside the terminal. Shell Pilot has always shown you what a command does as you type it, but git was a single page covering the git executable and nothing else — the moment you typed a space, help went away. This release adds 48 subcommand pages and teaches the help system to read the whole line.
Start typing git rebase and the description capsule under the prompt now reads git rebase — what it does, not what git does. Keep going to git rebase -i HEAD~3 and it stays on the rebase page. Delete back to just git and it swaps to the general git page. The same applies to the fuller help panel, whether it opens on its own or you summon it with ⌘⇧M.
Previously none of this worked. Help matched the entire typed line against a command name, so a line with any space in it matched nothing at all and the capsule simply did not appear. Help now walks the line back from the longest match: git cherry-pick abc1234 tries git cherry-pick first, then git, and shows whichever it finds.
It also looks past the words you put in front of a command. All of these land on the page you would expect:
sudo git push --force → git pushGIT_TRACE=1 git fetch → git fetchenv GIT_PAGER=cat git log → git logtime git status → git statussudo, env, command, nohup, time and nice are skipped, as is any leading NAME=value assignment. Typed on its own, though, a wrapper is still a command — bare sudo shows the sudo page. And a half-typed subcommand falls back rather than flickering: git com shows the general git page until you finish the word.
Type # at the prompt to search by meaning instead of by name. That search now understands git vocabulary — 42 new concepts and 13 expanded ones. Try #undo last commit, #stash changes, #who changed this line, #squash commits, #find the bad commit, #discard local changes, #recover a lost commit.
The vocabulary covers undo, amend and squash; staging and unstaging; stashing; branches, merging, rebasing and conflicts; cherry-picking, bisecting and blame; tags; remotes, origin and upstream; fetch, pull, push and clone; diffs, logs and history; revert and reset; worktrees and submodules; gitignore and untracked files; the reflog and lost commits; patches, archives and shortlogs.
Each one carries a usage line, between four and ten options, and between five and eight worked examples.
init · clone · add · status · commit · push · pull · fetch · branch · checkout · switch · restore · merge · rebase · reset · revert · log · diff · show · stash · tag · remote · cherry-pick · bisect · blame · grep · mv · rm · clean · reflog · worktree · submodule · config · apply · format-patch · am · archive · describe · shortlog · rev-parse · ls-files · gc · fsck · notes · range-diff · sparse-checkout · maintenance · help
The catalogue as a whole grows from 127 commands to 175.
Reference material is worth nothing if you cannot trust it, so none of it was written from memory. Every flag on every one of these pages was checked against git <subcommand> -h and man git-<subcommand> on git 2.50.1. Nothing was invented.
That check also caught an existing error. The general git page listed --dry-run and --verbose as top-level options. They are not — they belong to individual subcommands. They have been replaced with the flags git itself actually accepts: -C <path>, -c <name>=<value>, --git-dir=, --work-tree=, -p/--paginate, -P/--no-pager, --bare, -v/--version and -h/--help.
The help panel and popover titles now fit two-word names such as git cherry-pick on one line, scaling the text down to 70% where needed instead of truncating it or wrapping onto a second line.
313 tests pass across 26 suites, up from 300 in 25. The new suite checks that all 48 subcommands are present with unique names, that every page carries a usage line, options and examples, and that every example is a runnable git command line — plus the prefix resolution, the wrapper and environment-variable stripping, empty and whitespace-only input, the auto-show panel following the subcommand as you type, manual ⌘⇧M on a full command line, and the plain-English search route into the git pages.
# searches still rank badly. The search vocabulary contains a single-letter entry, c, mapping to clang, gcc and make. Because entries match by substring, any short query containing the letter c drags those in — so #bisect can still show make, cd or cp above git bisect. Removing the entry was tried for this release and backed out: it shifted results elsewhere for the worse, pushing git stash out of the top three for #stash changes. The real fix belongs in how results are ranked rather than in the vocabulary, and is still to come. Typing more of the query works around it in the meantime.git subcommands specifically. Other multi-word commands resolve correctly through the same mechanism, but only where the catalogue has a page for them.