Version control

Press Space g to choose a version-control action.

For a walkthrough from an edit to a staged change, start with Review and stage changes.

Version-control commands use the vcs_ prefix in keybindings and vcs- in command mode. Commands that open pickers use the _picker suffix in keybindings. Git is currently the only supported provider.

s means status, S stashes, f file history, and l log.

Find other version-control commands by searching for vcs- in the command palette (Space ?).

Space i also inspects a change, and Space B toggles inline blame.

Previously, Space g opened changed files directly; that action is now Space g s. To open changed files directly again, replace the version-control menu with this binding in config.toml:

[keys.normal.space]
g = "vcs_changed_file_picker"

[keys.select.space]
g = "vcs_changed_file_picker"

Staging changes and saving or applying stashes require the git executable on PATH.

Reviewing changes

HEAD is your checked-out commit, usually the latest commit on the current branch. Git’s staging area holds the changes you have selected for your next commit. A hunk is a group of changed lines. Reviews compare two versions of a file without saving it or changing the staging area.

Changed files

Press Space g s to browse changes within the workspace. To browse the whole repository, run :vcs-repository-changes.

The picker has separate staged and unstaged columns. Each path appears once, including files with both kinds of changes. New files are labeled added when staged and untracked before they are added to Git.

The preview shows the selected file’s diff. Use Alt-p / Alt-n to choose which versions to compare:

The unsaved comparison is available for listed files with a modified text buffer. The preview starts with unsaved edits when available, then unstaged changes, then staged changes. Alt-Left / Alt-Right also switch comparisons, but some terminals use those keys for word movement.

Conflicts with marker lines appear as labeled sections in the preview, including unsaved edits. Press Enter to open the file and resolve the conflicts. Once the markers are removed, the preview shows a diff so you can review the result.

For deleted files, Enter opens a review. Alt-o also works when the preview is hidden. After opening a diff, Space ' restores the picker, and further selections open as reviews. Use Ctrl-v / Ctrl-s to open them in a vertical / horizontal split.

Results refresh as files change, keeping the query and selected file. Remap these controls under [keys.git-picker]; shared navigation uses [keys.picker]. See Component keys.

Review buffers

Run :vcs-diff to compare the current file with HEAD, including unsaved edits. Choose another comparison with:

These comparisons also work before the repository’s first commit. For deleted files, open the review from the changed-file picker.

For conflicted files, use :vcs-diff to compare with HEAD. Save and stage the resolved file before choosing another comparison.

Reviews are read-only buffers. Use normal movement, search, selection, yank, wrapping, and view commands. Reviews appear in the buffer picker; use the usual buffer or view commands to close them. Ctrl-o returns through the jumplist.

The gutter shows old and new line numbers and a + or − marker. Added and removed lines have background highlights and the source language’s syntax colors when available. Hunk headers separate groups of changes. Use [g / ]g to move between hunks, or [G / ]G for the first / last hunk.

Buffer names show the filename and comparison, for example editor.rs [diff: staged]. Separate reviews of the same comparison receive numbered suffixes. The statusline shows change counts, the active comparison method, and whether the review is loading.

Enter can jump into the current file only when it matches the updated version in the comparison. Removed lines jump to their deletion location in that file. If the file differs from the version being reviewed, use :vcs-diff-open-file without a line jump.

Current-file reviews update automatically as you edit, stage changes, or change files outside Mitos. Updates apply to every view of each affected review. Buffer comparisons use the file on disk if you close its source buffer, and follow the buffer again when you reopen it.

External updates follow your file watching and polling settings. Use :vcs-diff-refresh to retry a failed read or update a review when watching and polling are disabled. Historical comparisons keep the chosen commits and the buffer text shown when you opened them, even after a refresh.

To review two files side by side:

1. Press Space g s, select a file, and press Alt-o.
2. Press Space ' to restore the picker and select another file.
3. Press Ctrl-v to open the second diff in a vertical split.

Use Ctrl-w v / Ctrl-w s to split an existing review. The command palette also lists the diff commands.

Binary files and submodules show an explanation instead of a text diff. Very large files may be rejected, or their diffs shortened with a notice.

Inspecting the current change

Press Space i or run :vcs-show-change to inspect the change at the cursor in a popup. It compares HEAD with the current buffer, including unsaved edits, and shows added and removed lines with context and line numbers.

Use Ctrl-d / Ctrl-u or Page Down / Page Up to scroll, Left / Right to scroll horizontally, and Esc to close.

Press r to restore the inspected change from HEAD. The popup closes; press u in the buffer to undo the restoration. Only the change at the inspected cursor is restored, even if nearby changes appear in the popup. Restoration does not save the file or change Git’s staging area. If the buffer, cursor selection, or repository changes while the popup is open, reopen it before restoring.

Remap scrolling and closing under [keys.popup], and horizontal scrolling and restoration under [keys.diff]. For example:

[keys.diff]
r = "unbound"
A-r = "restore"

The popup shows the configured restoration shortcut below the change.

Reviewing changes

Reviews show the exact added and removed lines, whitespace, line numbers, and counts. When source syntax is available, matching code across line breaks helps emphasize the parts that changed. Comments, string contents, and literal markup whitespace remain significant. A layout only label means the syntax matched while the text’s layout changed.

Syntax highlighting uses the original source on each side. Files without usable syntax, parse errors, and comparisons beyond the syntax limits keep ordinary line emphasis. No setup is required.

Comparison does not prove that code behaves the same. Moved blocks still appear as removed and added text.

Change navigation and restoration

In editable buffers, diff gutters compare your text with HEAD, including unsaved edits. Use a count such as 3]g to jump forward three changes.

Restoring replaces each selected hunk in the current buffer. Use u to undo it. The command does not save the file or change Git’s staging area. Navigation and restoration use the exact line changes.

Git picker actions

Use these shortcuts directly in the changed-file picker (Space g s). Actions affect the selected file’s repository, or the picker’s repository when no file is selected. Staging, unstaging, stashing, and applying stashes require workspace trust. Use :workspace-trust to approve the workspace.

The picker shows these shortcuts below the file list, including any remappings. Alt-a offers the same actions in a menu. Staging and unstaging keep the query and selected file.

Staging does not save unsaved buffer edits. Staging and unstaging affect the entire file, including both paths of a rename.

Stashing saves staged, unstaged, and untracked files throughout the repository, then restores its working tree to HEAD. Ignored files and changes inside submodules are excluded. Save modified buffers in that repository first.

While stashing or applying a stash, file saves in that repository are temporarily blocked. Mitos updates open buffers afterwards. Edits you make during the operation are kept; saving them may require :w! because Git changed the file on disk.

Stashes

Press Alt-l in the changed-file picker or choose vcs_stash_picker from the command palette to browse the newest 500 stashes. Press Enter to browse a stash’s saved staged version, working tree, and untracked files, then Enter on a file to review its saved changes. Alt-Enter keeps the picker open.

In the stash picker, use these shortcuts directly or choose an action with Alt-a:

Applying a stash asks for confirmation. Save modified buffers in that repository first. Git may leave conflicts to resolve; the stash is kept even if applying it fails. Mitos refreshes the resulting files and staged changes.

Remap Git and stash actions under [keys.git-picker] and [keys.stash-picker]. See Component keys.

Branches and worktrees

Run :vcs-branches to browse local branches. Select a branch and press Enter to switch to it. Save edited files in that repository first.

Press Alt-n to create a branch at HEAD without switching. Press Alt-d to confirm deletion of the selected branch. Deletion fails if the branch is unmerged or checked out in any worktree. The picker stays open and refreshes after the action. Remap these shortcuts under [keys.branch-picker].

These commands use the current file’s repository, or the original repository when viewing a review or an older file version. In an unnamed buffer, they use the current directory. Actions that change the repository require workspace trust.

Branch and worktree actions use Git when repository hooks must run; otherwise they do not require a Git executable. Switching keeps unrelated staged and unstaged edits and refuses to overwrite modified, untracked, or ignored files. Save edited buffers first. Conflicted or sparse indexes and switches that change submodules require a terminal checkout. To check out a remote branch for the first time, use Git in your terminal.

Worktrees

A worktree is a separate folder where you can work on another branch of the same repository. Run :vcs-worktrees to browse worktrees, then press Enter to open one in the file picker. Your open buffers and unsaved edits are kept.

Press Alt-n to enter a new worktree path, relative to this picker’s repository root, then an existing branch name (leave it empty for detached HEAD). Press Alt-d to confirm removal of the selected worktree. For an unavailable worktree, the same action removes only its Git registration, keeping its branch and any remaining files. If the worktree is on an unmounted drive, reconnect it or lock it instead of removing its registration. Press Alt-l to lock a linked worktree against removal and pruning, or Alt-u to unlock it. Locking an already locked worktree preserves its existing reason. The main worktree cannot be locked. These actions require workspace trust and work even when a linked worktree folder is temporarily unavailable. Remap these shortcuts under [keys.worktree-picker]. Branch and worktree pickers show the active shortcuts along their bottom border when picker.show-keybindings is enabled.

To create a branch and work in a separate folder, run these commands from the repository folder:

:vcs-branch-create fix-login
:vcs-worktree-create ../project-fix-login fix-login
:vcs-worktree-open ../project-fix-login

Choose a new folder outside the current checkout. The branch must already exist and cannot be open in another worktree. Omit the branch name to check out the current commit without a branch (detached HEAD).

To remove a worktree, open a file in another worktree and change directory out of the one you want to remove. Save or close its edited files first. It must have no modified, untracked, or ignored files. Removal asks for confirmation and keeps the branch. The main checkout and locked worktrees cannot be removed.

Reopen the picker to see branch or worktree changes made outside Mitos.

Fetch, pull, and push

Use these commands to download and upload commits. They use your configured Git remotes, such as origin, and require workspace trust.

When exactly one remote is configured, its name is optional. With several remotes, include its name, for example :vcs-fetch origin.

Save edited files before pulling. Pull updates the current branch only when it can move forward without a merge (fast-forward). If both your branch and the remote have new commits, use Git in your terminal to merge or rebase them.

Push uploads only the current branch, using its upstream branch name on the chosen remote if one is configured. Otherwise, it uses the local branch name. Tags are not included. Pull and push require a local branch; they cannot run from detached HEAD.

Mitos uses your Git authentication settings. If Git needs you to sign in, set up authentication in your terminal, then retry in Mitos. For details about a connection failure, run the matching Git command in your terminal.

Git history

Use history to review older changes or compare a past version with your current buffer. Browsing history does not check out revisions or change files or staged changes. Choose vcs_file_history_picker or vcs_history_picker from the command palette (Space ?), or use the commands below. The committed column shows committer dates in UTC.

Older commits load automatically as you scroll toward the end of the list. Searching also loads older commits; clear the query to stop searching further back. The status below the search field shows whether more history is available or loading.

A ? in the result count, such as 80/?, means the full history has not loaded. For loading controls, see loading large collections.

File history

Run :vcs-file-history to browse commits that changed the current file, following detected renames. The preview shows the selected commit’s diff against its first parent. Ctrl-t hides or shows the preview; Alt-k / Alt-j or Alt-Up / Alt-Down scroll it.

Press Enter to open the diff in a review buffer. Ctrl-v / Ctrl-s open it in a vertical / horizontal split. Space ' restores the picker with its query and selection, so you can open another comparison alongside it.

Use Alt-a to open the file’s version at that commit or choose another parent of a merge commit. When browsing from an editable file buffer, it also offers a comparison with that buffer, including unsaved edits.

File history follows the first parent of a merge: the previous commit on the branch that received the merge. Use repository history to see individual commits from merged branches.

Repository history

Run :vcs-history to browse commits leading to HEAD, including commits from merged branches. It uses the current file’s repository, or the current directory when no file is open. Run the command again after switching branches to browse the new branch.

The preview shows the full commit message followed by all changed files in one scrollable patch. Alt-o opens the combined preview in a read-only buffer. Alt-k / Alt-j scroll through the message and changes; Ctrl-t hides or shows the preview. Press Enter to browse the commit’s changed files. Merges compare with their first parent by default; use Alt-a to choose another parent. Alt-a also offers historical versions and comparisons with an open buffer for that file.

In the changed-file browser, Alt-h returns to the commit browser with its query and selection. Space ' restores the last picker after opening a review.

Older versions and comparisons

Historical versions open in read-only buffers with syntax highlighting. In a historical diff, Enter on a removed line opens the original version; on an added or unchanged line it opens the updated version. When comparing with unsaved edits, it opens the text shown when you started the review. Use :vcs-diff-open-file to open the current file instead.

Refreshing a historical comparison keeps the same revisions and any buffer text from when you opened it. Start a new comparison to include newer edits.

Remap history actions under [keys.history-picker], which inherits shared picker bindings. See Component keys.

Blame details

Run :vcs-blame or choose vcs_blame_line from the command palette to inspect the commit that last changed the current line. The popup shows the full commit ID, author name and email, date, and commit message. Lines with uncommitted changes report “Not committed yet”.

Copy actions use [keys.blame] with copy_commit_id and copy_message. Scrolling and closing use [keys.popup].

Ignored revisions

Blame respects Git’s blame.ignoreRevsFile configuration. Without that setting, Mitos uses .git-blame-ignore-revs in the working tree root if it exists. Both the popup and inline annotations attribute ignored changes to earlier commits where possible. Ignoring revisions requires git on your PATH.

Ignore files contain one full commit ID per line; blank lines and # comments are allowed. Configure another file with:

git config blame.ignoreRevsFile path/to/ignored-revisions

The setting can be repeated to read several files. An empty value resets the file list and disables automatic .git-blame-ignore-revs discovery. Mitos also accepts repeated blame.ignoreRevs values for individual revisions.

Inline blame

Show who last changed the current line with Space B. Press it again to hide annotations. To show them by default, add this to config.toml:

[editor.inline-blame]
show = "cursor-line"
format = "{author}: {title}"

Use show = "all-lines" for all visible lines, or "never" to hide them. Turning annotations back on restores the previous mode, defaulting to "cursor-line". Blank lines and uncommitted changes have no inline annotation. The :vcs-blame popup works whether annotations are shown or hidden.

Format

The default format is {author}, {time-ago} • {title} • {commit}. Available placeholders are:

Resolving conflicts

Press Space g s and open a conflicted file. Use ]m to move to the next conflict or [m to move to the previous one.

Place the cursor inside a conflict and press Space a. Choose Accept current, Accept incoming, or Accept both (current then incoming) to keep that text. The menu also includes other available code actions.

Press u to undo a choice. If you keep both sides, review and edit the combined text. When you have resolved every conflict, save the file and stage it.

You can also resolve conflicts with commands:

During a merge, current is the branch you have checked out and incoming is the branch you are merging. During a rebase, current is the branch you are rebasing onto, including commits already applied; incoming is the commit being applied.

To see the whole file for either side, run :vcs-conflict-source current or :vcs-conflict-source incoming. Use :vcs-conflict-source base to see the original version. Each version opens in a read-only split. Close it with :q.

If Mitos cannot recognize a conflict, edit the file and remove the marker lines yourself.