Changes
The Changes tab shows the working tree and the index for the open repository. It is where most of the work happens: read the diff, stage the part you mean, write a message, commit.
The layout
- File list — staged and unstaged entries, with status letters, in tree or flat order. Sorting and tree mode are set in the list header and remembered per installation.
- Diff pane — the diff for the selected file or hunk. Side-by-side or unified, following the default set in Settings; context size is also a setting. The commit detail view has its own ignore-whitespace toggle.
- Commit composer — message field, commit button, and the staged file summary.
- Sync controls — fetch, pull and push for the current branch.
Untracked files appear in the list when Show untracked is on. Files that are both staged and modified appear twice, once in each section, which is what git status reports.
Staging
Three levels, all reached from the same key:
| Level | How | What it writes |
|---|---|---|
| File | Select a file, press Space | The whole file, staged or unstaged depending on the section |
| Hunk | Select a hunk in the diff, press Space | Only that hunk’s changes |
| Lines | Select lines in a hunk, press Space | Only those lines, with the surrounding context kept intact |
Unstaging works the same way from the staged section. Stage all and Unstage all are on the list header.
The stale guard
Every staging request carries a fingerprint of the diff it was computed from. Before writing the index, the service recomputes the diff and compares fingerprints. If they differ — the file was saved by an editor, a formatter ran, a Git hook rewrote it — the request is rejected with the git_stale error, the index is left untouched, and the diff reloads.
This is deliberate. Applying a stored patch to a file that changed since you read it can stage code you never saw. The cost is one extra keystroke: read the new diff and stage again.
The same rule applies to discarding a hunk or a selection: a stale request changes nothing.
Discarding changes
Backspace or Delete discards the selected change. Before anything is reverted, the service writes a recovery snapshot of the affected file, patch or staged state.
- A file with unstaged changes is reverted to the index content; staging is untouched.
- A file that is staged only is restored from
HEAD, which also removes it from the index. - A file with both appears in both sections; discarding one row leaves the other alone, and each discard has its own snapshot.
If the snapshot cannot be written, the discard does not run. That ordering is intentional: an unrecoverable discard is worse than a failed one.
Discarded work is restorable from the recovery centre until the snapshot expires.
Batch outcomes
Operations that affect more than one file — stage all, unstage all, discard several, delete several — produce one outcome per path:
| Outcome | Meaning |
|---|---|
succeeded | The path was updated |
failed | Git returned an error for that path |
skipped | The path no longer needed the operation, or a precondition failed |
A batch that cannot finish — a lock file, a cancelled operation, a killed process — leaves a journal entry next to the local database. The status bar then shows an interrupted-batch notice with the completed and total path counts; clicking it opens the recovery centre, and Retry failed replays only the paths that failed, after checking for leftover lock files.
Reading diffs
- Image diffs render the before and after side by side with dimensions and file size, for formats the viewer supports.
- Syntax highlighting colours the diff using the file extension; unknown types fall back to plain text.
- Find in diff (
Cmd/Ctrl + F) highlights matches inside the current diff and cycles through them with Enter. - Context lines are adjustable from 0 to 20 in Settings.
- The commit detail view has an ignore whitespace toggle for reviewing reformat-only commits.
Very large image blobs are not decoded for the image diff; the pane says the image is too large instead of drawing a partial or blank result.
The commit composer
- Stage what should be in the commit.
- Type the message, or ask the assistant to draft one from the staged diff.
- Press
Cmd/Ctrl + Enter.
The commit uses the staged content only. If nothing is staged, the composer offers Stage all — or uses the Stage all by default setting so a normal commit behaves like git commit -a when you want that.
Commit identity comes from user.name and user.email. Both are editable in Settings → Git, either for the repository or globally, and the identity editor writes through Git config rather than editing .git/config by hand.
Commit signing is controlled by commit.gpgsign in the repository plus the signing key configured in Settings. Signature format (OpenPGP or SSH) is stored per repository, not per installation.
What the composer does not do
- It does not amend by default. Amend is an explicit action in History.
- It does not skip hooks. Hooks run as Git would run them, and their output appears in Git Output.
- It does not commit files outside the repository root.