Git Integration

Iruka's git support exists for one job: reading back what just happened to a repository, and turning it into sensible commits. That is the loop you're in when a coding agent has been working in a folder for ten minutes — you need to see every file it touched, decide which of those changes you want, and commit them.

It is not a git client. There is no branch switcher, no history browser, no log graph, no merge editor, no pull-request reviewer. Iruka does the handful of commands that belong next to a file browser and hands everything else to the terminal pane at the bottom of the window, which shares the folder you're looking at. If you want git rebase -i, type it — the strip above will notice and keep up.

Everything below appears only inside a repository. Elsewhere, none of it is there.

The status strip

At the bottom of the file list, whenever the folder you're in is inside a repository:

Fetch, Pull and Push run in the terminal pane, which opens by itself to show them. That is deliberate: they talk to a server, a server can ask for a password or a passphrase, and a prompt needs somewhere to appear. Everything else — staging, committing, discarding — runs directly and reports what git said, so it works even from a window where the terminal isn't open.

Pull merges by default. If you've configured pull.rebase or pull.ff yourself, your setting is used instead — Iruka doesn't override a choice you've made.

Status badges

Changed files show a coloured letter beside the name, in list, icon and column views:

Folders carry the status of what's inside them, so you can see which part of a tree an agent has been in without opening anything. A folder holding a conflict is always badged U, even if everything else under it is an ordinary edit.

The review pane

⇧⌘U, or click the ● 12 👁 count. This is the centre of the whole feature.

The pane splits in two: every changed file down one side, the diff of whichever one you pick on the other. Untracked files are included and shown in full as additions — those are usually precisely the files that were just created, and a plain git diff says nothing about them at all. Deleted files are there too.

• ⌥↓ and ⌥↑ step through the files. The file list keeps its own ↑/↓ throughout, so arrowing through folders is untouched.
• Each row shows what it gained and lost — +35 −24 — so you can see which files are worth opening before you open any of them.
• The header names the repository being reviewed. The pane belongs to the window and stays put while you browse, so this is regularly not the folder you're currently in.
• ⌘R re-reads the repository, and it re-reads itself every few seconds anyway — pace set by how long the last read took, so a huge repository doesn't become a burden. Leave it open while an agent works and watch the list fill in.
• Right-click a row for Reveal in File List, Open, Show in Finder, Copy Path, and Discard Changes… where that means something.
• ⌘= / ⌘− / ⌘0 resize the diff and the list beside it.

Building a commit

Every row has a checkbox: ticked means the next commit includes that file. It runs git add; unticking runs git reset, which only ever changes what the commit would record — your edits are never touched.

• The box at the top of the list ticks or unticks everything.
• A file you staged and then edited again shows a dash rather than a tick: a commit would record the earlier version and leave your newer edits behind. Clicking stages the rest.
• Commit… appears once anything is staged, and opens with stage everything first switched off — you have just been picking files deliberately, and having the sheet undo that in one keystroke would be the opposite of the point.

This is how you split an agent's work into commits that make sense, rather than one commit called "changes".

Staging and discarding from the file list

Right-click any file:

• Stage Changes / Unstage — the index only; nothing on disk moves.
• Stage All Changes — the whole working tree.
• Discard Changes… — put the file back the way your last commit has it. It asks first, and the question says what you're losing: how many lines, that staged changes go too, and that this does not go to the Trash and cannot be undone. Return cancels; the red button has to be clicked.
• Restore From Last Commit… — the same entry on a file you deleted, which simply brings it back.
• Initialize Git Repository Here… — on empty space, in a folder that isn't in a repository yet. It shows the full path and asks, because git init in your home folder is a mistake that stays quiet for weeks.

Files git has never seen aren't offered a discard: git's answer for an unwanted new file is to delete it, and Move to Trash is a few lines up the same menu — recoverable, which discard isn't.

Unfinished operations

Agents leave repositories part-way through things. When git is mid-merge, rebase, cherry-pick, revert or bisect, a red pill says so beside the branch name, and hovering it names the command that finishes the job.

While that is true, Iruka gets out of the way rather than helping you make it worse:

• Conflicted files have no checkbox and no Stage entry. Ticking one runs git add, and on an unmerged path that is precisely the command that marks the conflict resolved — one click, on a row that used to say "modified", accepting whichever side is in the file, conflict markers and all.
• Stage All disappears, everywhere it exists. git add -A does not skip unmerged paths.
• Commit… is withheld part-way through a rebase, cherry-pick, revert or bisect, because committing there makes an ordinary commit that the operation then carries straight past. A merge keeps its Commit button — a merge really does end in one.

Resolving conflicts is a text-editing job and Iruka has no merge editor. Open the files, deal with the markers, git add them, and finish in the terminal.

Comparing

⇧⌘C compares whatever is selected, in a pane beside the file list rather than a window:

A folder comparison lists what's only on the left, only on the right, and changed in both, with line counts, streaming in as the trees are walked. It only ever tells you — there is no button in it that copies, moves or deletes anything. The ⇄ in the header swaps the two sides. (Not for git comparisons: there the left side is a commit and the right is your working tree.)

If you have Xcode's tools, a FileMerge button hands the same two files over for editing.

Credentials and authentication

Iruka stores no keys, passwords or tokens and never will.

• Fetch, Pull and Push run in the terminal pane, where a password, an ssh passphrase or a host-key question has a tty to appear on and you can answer it.
• Iruka finds your ssh agent even when launched from Finder, so a key held by the macOS agent, 1Password or Secretive works for pushes without any setup.
• Everything that doesn't touch the network runs with prompts disabled, so it fails with a message rather than hanging on a question nobody can see.

GitHub CLI (gh)

The Pull Request button appears when gh is installed and you're on a branch the remote has. It opens the new-PR page in your browser, filled in for that branch — a handoff, not a pull-request client.

If gh is installed but not signed in, the button is still there and tells you to run:

gh auth login

in the terminal below. A private repository needs that login before the PR page can be reached at all. gh authenticated by GH_TOKEN in your shell profile is recognised too.

Note that gh auth logout does not stop git push working: pushing over HTTPS uses git's own credential helper — usually the macOS keychain — which stores your credentials separately from gh. The two are independent.

What Iruka deliberately doesn't do

Branch creation and switching, history and log, cherry-picking, interactive rebase, stashing, tags, submodule management, blame, bisect, merge conflict editing, pull-request review threads, CI status. All of it belongs in the terminal, and the terminal is right there sharing your working directory — cd in one and the other follows.

The dividing line is simple: Iruka does the commands that are about the files you're looking at. Everything about the shape of history is a different job.

Shortcuts