Skip to content

Feature overview

Everything it does, and where it stops.

GitAegis is a native desktop Git client with a recovery layer underneath it. The recovery layer is the reason the product exists; the Git client is the reason you’d open it every day. Both are documented here with their limits attached.
Download GitAegisSee how recovery works

macOS 12 or later · Requires Git 2.38.0 or newer, already installed · Account optional

GitAegis
The GitAegis mode rail, showing the five modes (Home, Work, History, Review and Doctor) with Work active and the Operation Preview open over the workspace.
Five modes, one rail. Work is open here, with a plan waiting for approval.

Three questions a Git client should be able to answer

  1. What is about to happen?

    Not “are you sure?”: the actual commands, the risk level, the preconditions that were checked, and what will be saved before any of it runs.

    The operation model

    The Operation Preview's intent line for a hard reset, with its Destructive risk badge, the standard capsule that will be taken first, and rollback availability.
    The plan, before it runs: intent, risk, capsule, rollback.

  2. What already happened?

    Including the things the client itself didn't do: your terminal, a build script, an agent running in another window.

    The timeline

    Flight Recorder timeline events including stash and ref changes detected outside GitAegis, each recorded as what changed rather than how.
    External changes land on the same timeline as the app's own operations.

  3. Can I put it back?

    With a real answer. Not “probably, try the reflog.”

    How capsules work

    The restore dialog of a recovery capsule, with a per-domain checkbox for refs, index, staged changes, working-tree changes, untracked files and operation state.
    Put back the whole capsule, or only the domain you actually need.

Most clients answer the third with optimism. GitAegis answers it by having taken a snapshot before the operation started, and by refusing to start when it couldn’t.

Five modes, five keys

One window, five modes, and the recovery layer lives in the fifth.

  1. ⌘1Home

    the repository catalogue

    Git Toolkit →

  2. ⌘2Work

    status, staging and commits

    Git Toolkit →Safe Operations →

  3. ⌘3History

    the graph, compare and search

    History & Search →

  4. ⌘4Review

    local review: compare refs, read the unpublished commit series, go over the working tree

    No capability page of its own: Review compares refs and reads the unpublished series in the client.

  5. ⌘5Doctor

    diagnosis and repairthe recovery layer

    Doctor →Recovery Capsules →Flight Recorder →Lost Work →

Recovery

The layer that decides whether the rest of this matters.

Recovery Capsules

A snapshot across six domains (refs, index, staged changes, working changes, untracked files, operation state) written to disk before the first command runs. Restore all six, or only the one you need. If the capsule cannot be written, the operation is blocked and never executes.

Read more

Flight Recorder

A timeline of what happened to the repository, including what GitAegis did not cause. A filesystem watcher notices when your terminal moves a ref or rewrites your index, and reconciliation fills in what changed while the app was closed. Events that reference a capsule restore from it.

Read more

Lost Work

Finds commits nothing points at any more, across the reflog, the stash list, Flight Recorder before-oids, refs/aegis/ recovery refs, capsule bundles, sibling worktrees, and a bounded fsck. Then offers to put a branch back on them.

Read more

Safe Operations

Every mutation is a transaction: intent, risk level, preconditions, the exact commands, a checkpoint, a rehearsal, a rollback plan. Destructive plans open the Operation Preview drawer. Safe Mode locks mutating controls when the index or HEAD can't be trusted.

Read more

Everyday Git

The part you use when nothing is on fire.

Git Toolkit

Hunk- and line-level staging, branches, tags, remotes, refs, worktrees, stashes, submodules, LFS, conflict resolution with stage-1/2/3 read and sequencer control, clone with cancellable streamed progress, and a ⌘K palette over real intents.

Read more

History & Search

Commit graph, compare, file history, blame, search across message, author, path and content, bisect with a visible candidate range, and reflog browsing.

Read more

Doctor

Scans for real damage (not style opinions), shows the evidence behind each finding, and proposes repairs that take a capsule first. Exports plain or technical reports with optional path redaction.

Read more
domains captured in every capsule
6
modes, ⌘1 through ⌘5
5
the Git floor: your Git, never bundled
2.38.0
HTTP clients compiled into the local edition
0

How the pieces fit together

They are not twelve separate features. They are one loop, and each stage feeds the next.

  1. You choose an intent.

    Not a button that means “run this command”. An intent: rebase feature/payment-retry onto main. The orchestrator turns that into a plan carrying a risk level, the preconditions it must check, and the exact git invocations it will make.

  2. Preconditions are checked, and can veto.

    A dirty working tree, a detached HEAD, an in-progress sequencer, a missing upstream, a branch lease held by another session. A failed precondition stops the plan here, before anything is written.

  3. The capsule is taken.

    Six domains, to disk, before the first command. This is the point at which the plan becomes reversible. If the write fails (disk full, permission denied, a path the process can’t read) the operation is refused. Not warned about. Refused.

    How capsules work →

  4. The plan is rehearsed.

    The orchestrator runs the plan against a copy before it touches your repository, so a plan that would fail halfway fails in the rehearsal instead.

  5. Destructive plans are shown before they run.

    The Operation Preview drawer carries the intent, the commands, the capsule that has already been taken, the rehearsal result, and the rollback path you would use. You approve a plan, not a dialog.

    The operation model →

  6. It executes, and the journal records it.

    The Operation Journal stores the plan, the commands as they ran, the capsule reference and the outcome. If the process dies mid-transaction, recover_incomplete reconciles the unfinished entry to requires-intervention on the next launch rather than leaving it silently half-applied.

  7. The Flight Recorder keeps watching.

    Including after the operation ends, and including changes GitAegis didn’t make. When your terminal moves a ref or rewrites your index, that lands on the same timeline as the operations that came from the app.

    The timeline →

  8. Nothing in the loop ever deletes objects.

    git gc, git prune and git reflog expire are the commands that make objects stop existing, and no path in the product runs them. Not gated, not behind an advanced setting: absent. The loop only works if the objects are still there.
  1. Intent
    what you asked for, not which button you pressed
  2. Preconditions
    checked, and able to veto the plan
  3. Capsule
    written to disk, or the operation stops here
  4. Rehearsal
    the plan run against a copy first
  5. Previewdestructive plans
    the drawer, for a plan that can destroy work
  6. Execute
    the exact commands, as shown
  7. Journal
    plan, commands, capsule id, outcome
  8. Flight Recorder
    keeps watching, including what we didn't cause

…and the next intent starts from the state all of that recorded.

Lost Work reads the whole loop

Capsule bundles, recovery refs, the journal’s before-oids, the reflog. It is a spur off the loop rather than a stage in it. You reach for it when something is already missing.

Every stage leaves a reference behind, and every reference is a way back. That is what makes it a loop rather than a checklist.

It runs your Git, not a reimplementation of it.

GitAegis executes the Git already installed on your machine (2.38.0 or newer) using your SSH keys and your system keychain. It never bundles Git and never downloads one.

Every subprocess pins GIT_CONFIG_* and GIT_TERMINAL_PROMPT=0, so a hostile core.fsmonitor or core.pager value in a cloned .git/config can’t execute, and Git can never block invisibly on a password prompt you can’t see. Safe Mode additionally pins core.hooksPath=/dev/null. External diff and merge tools are never launched, in any mode.

The subprocess model

  • The Git already on your machine2.38.0 or newer, never bundled, never downloaded
  • GIT_TERMINAL_PROMPT=0Git can never block invisibly on a password prompt
  • GIT_CONFIG_*pinned per subprocess: a hostile cloned config can't execute
  • core.hooksPath=/dev/nulladditionally pinned in Safe Mode
  • External diff and merge toolsnever launched, in any mode
The same Git you run in your terminal, held to stricter environment rules.

Local Git work does not require an account.

GitAegis local Git work needs no account and no service. If you choose to sign in, the app contacts only its configured GitAegis account gateway; Git traffic still goes directly to the remotes you configured.

Local Git work never depends on the account connection. GitAegis does not currently include an automatic updater; you choose when to replace the app with a newer version.

There is no demonstration mode.

The interface never reaches past its typed client contract, and there is no fixture-data fallback. If the desktop core is unavailable, the app tells you and stops rather than rendering a surface that isn’t wired to anything.

The same rule governs this website: every product image on it is a capture of the real application, and a shot that has not been taken yet renders nothing at all.

What none of this does

The boundary is the product, so it is stated here rather than discovered later.

What GitAegis can put back

  • If a recovery capsule was taken, you can roll the operation back.
  • If a Flight Recorder event captured a state hash, you can roll back to that state.
  • If any reflog entry, ref, branch, stash, or capsule references a commit, Lost Work can recover it.
  • Outside those, it cannot, and GitAegis says so instead of pretending otherwise.

Specific limits, each stated again on its own page

  • Rebase state is not restored from a capsule. The capsule records that a rebase was in progress. It does not put the rebase directory back and does not resume one.
  • Config is not restored from a capsule. A sanitised copy of the config is captured so you can see what changed. GitAegis will not write it back over a change you made deliberately.
  • .gitattributes content filters cannot be wholesale disabled. A repository that defines a filter driver still runs it through Git, including during a restore.
  • bisect and a conflicted stash apply have no generic resume. Both are recorded and both are recoverable through their capsules. Neither is covered by the sequencer resume path that handles merge, rebase, cherry-pick and revert.
  • Work that was never written to disk is not recoverable. An unsaved editor buffer is not a Git object and no capsule can contain it.

The full recoverability boundary →

Questions this page raises

All questions →

Free edition · No account required

A recovery capsule before every risky Git operation.

You see the exact commands before they run, and the operation is refused if the capsule cannot be written.

Download GitAegisSee how recovery works →

Requires Git 2.38.0 or newer, already installed.

Every risky operation, in this order

  1. Previewthe exact commands, shown before anything runs
  2. Capsulerefs, index, staged and working changes, untracked files, operation state: written to disk first
  3. Executethe commands as shown, or not at all
  4. Journalplan, commands, capsule id, outcome
No capsule, no operation. Restore plans, previews, and takes its own capsule.