Git

crc drives the git you already have. Git runs on worker threads, so the editor never waits on it, and your hooks and commit signing stay exactly as Git has them configured.

Source Control

⌘⌥G opens Source Control in the sidebar. It shows:

• the current branch, how far it is ahead of or behind its upstream, and whether a merge or rebase is in progress
• staged and working-tree changes, file by file
• the diff of the selected file

Stage and commit

1. Select a changed file to see its diff.
2. Stage the whole file, or stage and unstage single hunks from the diff.
3. Write a message and press ⌘↩ to commit what is staged. Git › Commit… does the same from the menu.

Git reads the files as saved on disk, so save before staging an edit you want included.

Note

Hunk staging covers tracked text changes. Other kinds of change use the whole-file actions.

Branches and remotes

The Git menu has:

Command	Does
Switch Branch…	Lists your local branches in the palette. Type a name that is not one and it offers to create it.
Fetch	git fetch
Pull	git pull --ff-only: it never merges or rebases for you.
Push	git push, never forced. A branch with no upstream is pushed to origin and tracks it.
Refresh	Re-reads the status.

SSH remotes from the Dock

An app opened from the Dock does not get your shell’s SSH_AUTH_SOCK, so Git may not reach your SSH agent. Set ssh_auth_sock in settings to the path echo $SSH_AUTH_SOCK prints in a terminal.

Merge conflicts

When a merge, rebase, cherry-pick or stash pop stops on a conflict, however you ran it, crc finds the conflicted files. They get their own Conflicts group in Source Control, and the status line says MERGING, REBASING, CHERRY-PICKING or REVERTING. Click a conflicted file to open it at its first conflict.

A strip above the file counts what is left and switches between two views:

• Inline: the conflict stays in the text. The current side is washed in green, the incoming side in blue, and the conflict’s first line carries Accept Current, Accept Incoming, Accept Both and, when the markers include the common ancestor, Accept Base. You can also just edit the text by hand.
• Side by side: the current, base and incoming versions of the file in columns, each conflict’s sections next to each other and padded so the text after them lines up again. Each column has its own Accept button, and Accept Both is at the end of the row. Click any line to go back to it in the file.

Every accept is one undo step, and the file is left unsaved until you save it. Previous and Next walk the conflicts, wrapping around the file. Once no markers are left, Mark Resolved saves the file and stages it, which is how Git knows the conflict is over; it refuses while any markers remain, so they cannot end up in a commit. Finish the merge or rebase with Git as usual.

Everything in the strip is also in the Git menu, and so in the palette: Next Conflict, Previous Conflict, Accept Current, Accept Incoming, Accept Both, Accept Base, Conflicts Side by Side and Mark Resolved.

See the base

Git writes the common ancestor into the markers only with git config --global merge.conflictStyle zdiff3 (or diff3). With it, side by side gets a middle column and Accept Base is offered.

In the editor

• Gutter marks show lines added, changed or deleted compared with HEAD, as you type.
• Blame: the status line says who last changed the caret’s line, when, and the commit’s summary. Unsaved edits count as not committed yet.
• The branch is in the status line too.

Limits

Gutter marks compare with HEAD, not the index, and stop at files over 2 MiB. The full list is in Known limits.