GOT(1)

📦

version 0.126 · 6 versions

0.126 · alpine 3.24, ubuntu stonking (latest)
0.125 · nixos 26.05
0.129 · nixpkgs unstable
0.95 · ubuntu noble
0.119 · ubuntu resolute
0.111 · debian trixie, ubuntu questing

🎀 NAME 🎀

got — Game of Trees 🌳

okay so this is GOT(1) from the General Commands Manual, and yes bestie, we're about to make version control make sense 💖

🌸 SYNOPSIS 🌸

got [-hV] command [arg ...]

💅 DESCRIPTION 💅

got is a version control system which stores the history of tracked files in a Git repository, as used by the Git version control system. That repository format is described in git-repository(5).

got is a “distributed” version control system because every copy of a repository is writeable. Modifications made to files can be synchronized between repositories at any time. no central queen here, every repo gets main character energy 👑

Files managed by got must be checked out from the repository for modification. Checked out files are stored in a work tree which can be placed at an arbitrary directory in the filesystem hierarchy. The on-disk format of this work tree is described in got-worktree(5).

The got utility provides global and command-specific options. Global options must precede the command name, and are as follows:

-h — Display usage information and exit immediately.
-V, --version — Display program version and exit immediately.

The got utility only provides commands needed to perform version control tasks. Commands needed for repository maintenance tasks are provided by gotadmin(1). Git repository server functionality is provided by gotd(8). A repository interface for web browsers is provided by gotwebd(8). An interactive repository interface for the terminal is provided by tog(1).

The commands for got are as follows:

🌱 `init`

init [-A hashing-algorithm] [-b branch] repository-path

Create a new empty repository at the specified repository-path. fresh start, blank slate, iconic beginning ✨

After got init, the new repository must be populated before got checkout can be used. The got import command can be used to populate the new repository with data from a local directory. Alternatively, on a server running gotd(8), the new repository can be made available to got or git(1) clients by adding the repository to gotd.conf(5) and restarting gotd(8). Clients may then clone the new repository from the server, populate the cloned repository, and then populate the new repository on the server via got send or git push.

The options for got init are as follows:

-A hashing-algorithm — Configure the repository's hashing-algorithm used for the computation of Git object IDs. Possible values are sha1 (the default) or sha256.
-b branch — Make the repository's HEAD reference point to the specified branch instead of the default branch “main”.

The got init command is equivalent to gotadmin init.

📥 `import`

import [-b branch] [-I pattern] [-m message] [-r repository-path] directory

(alias: im) — yes she has a nickname, and she's serving 💅

Create an initial commit in a repository from the file hierarchy within the specified directory. The created commit will not have any parent commits, i.e. it will be a root commit. Also create a new reference which provides a branch name for the newly created commit. Show the path of each imported file to indicate progress.

The got import command requires the GOT_AUTHOR environment variable to be set, unless an author has been configured in got.conf(5) or Git's user.name and user.email configuration settings can be obtained from the repository's .git/config file or from Git's global ~/.gitconfig configuration file.

The options for got import are as follows:

-b branch — Create the specified branch. If this option is not specified, a branch corresponding to the repository's HEAD reference will be used. Use of this option is required if the branch resolved via the repository's HEAD reference already exists.
-I pattern — Ignore files or directories with a name which matches the specified pattern. This option may be specified multiple times to build a list of ignore patterns. The pattern follows the globbing rules documented in glob(7). Ignore patterns which end with a slash, “/”, will only match directories.
-m message — Use the specified log message when creating the new commit. Without the -m option, got import opens a temporary file in an editor where a log message can be written. Quitting the editor without saving the file will abort the import operation.
-r repository-path — Use the repository at the specified path. If not specified, assume the repository is located at or above the current working directory.

🧬 `clone`

clone [-almqv] [-b branch] [-i identity-file] [-J jumphost] [-R reference] repository-URL [directory]

(alias: cl) — the one that copies the whole vibe from somewhere else 🫶

Clone a Git repository at the specified repository-URL into the specified directory. If no directory is specified, the directory name will be derived from the name of the cloned repository. got clone will refuse to run if the directory already exists. no overwriting, bestie, we don't do that here 💀

The repository-URL specifies a protocol scheme, a server hostname, an optional port number separated from the hostname by a colon, and a path to the repository on the server:

scheme://hostname:port/path/to/repository

The following protocol schemes are supported:

git — The Git protocol as implemented by the git-daemon(1) server. Use of this protocol is discouraged since it supports neither authentication nor encryption.
ssh — The Git protocol wrapped in an authenticated and encrypted ssh(1) tunnel. With this protocol the hostname may contain an embedded username for ssh(1) to use: user@hostname
http — The “smart” Git HTTP protocol. Not compatible with servers using the “dumb” Git HTTP protocol. The “smart” Git HTTP protocol is supported by got clone and got fetch, but not by got send. Sending from a repository cloned over HTTP will require use of a send block in got.conf(5) to ensure that the “ssh://” protocol will be used by got send. Use of this protocol is discouraged since it supports neither authentication nor encryption.
https — The “smart” Git HTTP protocol wrapped in SSL/TLS.

Objects in the cloned repository are stored in a pack file which is downloaded from the server. This pack file will then be indexed to facilitate access to the objects stored within. If any objects in the pack file are stored in deltified form, all deltas will be fully resolved in order to compute the ID of such objects. This can take some time. More details about the pack file format are documented in git-repository(5).

got clone creates a remote repository entry in the got.conf(5) and config files of the cloned repository to store the repository-url and any branch or reference arguments for future use by got fetch or git-fetch(1).

The options for got clone are as follows:

-a — Fetch all branches from the remote repository's “refs/heads/” reference namespace and set fetch_all_branches in the cloned repository's got.conf(5) file for future use by got fetch. If this option is not specified, a branch resolved via the remote repository's HEAD reference will be fetched. Cannot be used together with the -b option.
-b branch — Fetch the specified branch from the remote repository's “refs/heads/” reference namespace. This option may be specified multiple times to build a list of branches to fetch. If the branch corresponding to the remote repository's HEAD reference is not in this list, the cloned repository's HEAD reference will be set to the first branch which was fetched. If this option is not specified, a branch resolved via the remote repository's HEAD reference will be fetched. Cannot be used together with the -a option.
-i identity-file — Specify an identity-file, containing a private SSH key, to use with SSH connections. The same option will be passed to ssh(1).
-J jumphost — Specify a jumphost to use with SSH connections. The same option will be passed to ssh(1).
-l — List branches and tags available for fetching from the remote repository and exit immediately. Cannot be used together with any of the other options except -q and -v.
-m — Create the cloned repository as a mirror of the original repository. This is useful if the cloned repository will not be used to store locally created commits. The repository's got.conf(5) and config files will be set up with the “mirror” option enabled, such that got fetch or git-fetch(1) will write incoming changes directly to branches in the “refs/heads/” reference namespace, rather than to branches in the “refs/remotes/” namespace. This avoids the usual requirement of having to run got rebase or got merge after got fetch in order to make incoming changes appear on branches in the “refs/heads/” namespace. But maintaining custom changes in the cloned repository becomes difficult since such changes will be at risk of being discarded whenever incoming changes are fetched.
-q — Suppress progress reporting output. The same option will be passed to ssh(1) if applicable.
-R reference — okay so this is the "gimme EXTRA stuff too" option 💖 In addition to the branches and tags that are gonna get fetched anyway, this pulls an arbitrary reference out of the remote repository's refs/ namespace. You can drop this flag multiple times to build up a whole little list of extra references to fetch. And bestie, the reference you name can be either a path to one specific reference, or a whole reference namespace, which makes literally every reference in that namespace get fetched. 🎀

Each reference gets mapped into the cloned repository's refs/remotes/ namespace, unless the -m option is being used to mirror references directly into the cloned repository's refs/ namespace.

Heads up: got clone will flat-out refuse to fetch references from the remote repository's refs/remotes/ or refs/got/ namespace. Not negotiable, no cap. 💅

-v — Verbose mode, aka the "tell me EVERYTHING" era 🗣️✨ This makes got clone print debugging messages to standard error output. If ssh(1) is in the picture, this option gets passed along to it too. Stack multiple -v options to crank the verbosity up — but the maximum is 3, so don't get greedy. 🙈

✨ fetch ✨ (alias: `fe`)

fetch [-adlqtvX] [-b branch] [-i identity-file] [-J jumphost] [-R
          reference] [-r repository-path] [remote-repository]

Pull those fresh new changes from a remote repository, slay 🦋 If you don't name a remote-repository, it just goes with origin like the default bestie it is. Where does the remote repository's URL come from? From the matching entry in got.conf(5), or from Git's config file of the local repository — whatever got clone set up for you back in the day. 💖

So here's the default tea ☕ — any branches configured in got.conf(5) for the remote-repository get fetched. And if you run got fetch inside a work tree, then this work tree's current branch gets fetched too, provided it's present on the server. But if there are no branches to fetch found in got.conf(5) or via a work tree, or those branches just aren't on the server? Then a branch resolved via the remote repository's HEAD reference gets fetched. Same energy if a HEAD reference for the remote-repository exists but its target no longer matches the remote HEAD — the new target branch gets fetched. And listen, you can override this whole default behaviour with the -a and -b options. Periodt. 👑

New changes get stored in a separate pack file downloaded from the server. And over time, tiny pack files are gonna accumulate as a result of you repeatedly running got fetch (very "my downloads folder" of it ngl 😭). For best performance, multiple small pack files can be combined into one single larger pack file with gotadmin cleanup. And the number of pack files in the repository? Displayed by gotadmin info. Iconic.

By default, branch references in the refs/remotes/ reference namespace get updated to point at the newly fetched commits. Then got rebase or got merge can be used to make those new changes visible on branches in the refs/heads/ namespace, merging incoming changes with the changes on those branches as necessary. 🫶

Now, if the repository was created as a mirror with got clone -m, then all branches in the refs/heads/ namespace get updated directly to match the corresponding branches in the remote repository. And if those branches had local commits, those commits will no longer be reachable via a reference and are therefore at risk of being discarded by Git's garbage collector or gotadmin cleanup.

⚠️ Warning: maintaining custom changes in a mirror repository is therefore discouraged. You've been warned, bestie. 💀

In any case, references in the refs/tags/ namespace will always be fetched and mapped directly to local references in the same namespace. No negotiations. ✨

The options for got fetch are as follows:

-a — Fetch all branches from the remote repository's refs/heads/ reference namespace. You can enable this by default for specific repositories in got.conf(5). Cannot be used together with the -b option. Pick a lane 💅
-b branch — Fetch the specified branch from the remote repository's refs/heads/ reference namespace. You may specify this option multiple times to build up a list of branches to fetch. Cannot be used together with the -a option. 😤
-d — Delete branches and tags from the local repository that are no longer present in the remote repository. Only references get deleted, okay? Any commit, tree, tag, and blob objects belonging to deleted branches or tags remain in the repository and may be removed separately with Git's garbage collector or gotadmin cleanup. So like, the refs leave the group chat but the receipts stay 🍓
-i identity-file — Specify an identity-file containing a private SSH key, to use with SSH connections. The same option gets passed along to ssh(1). 🔑
-J jumphost — Specify a jumphost (a jump host! the middle man ✨) to use with SSH connections. The same option gets passed along to ssh(1).
-l — List branches and tags available for fetching from the remote repository and exit immediately. Cannot be used together with any of the other options except -v, -q, and -r. It's a "just show me the menu" moment 🎀
-q — Suppress progress reporting output. If applicable, the same option gets passed to ssh(1). Quiet luxury, love that for us 🤫💅
-R reference — In addition to the branches and tags that are gonna be fetched, fetch an arbitrary reference from the remote repository's refs/ namespace. Specify it multiple times to build a list of extra references to fetch. The reference may be either a path to a specific reference, or a reference namespace, which means every reference in that namespace gets fetched. 🌈

Each reference gets mapped into the local repository's refs/remotes/ namespace — unless the local repository was created as a mirror with got clone -m, in which case references get mapped directly into the local repository's refs/ namespace.

Once a reference has been fetched, a branch based on it can be created with got branch if needed. Handy 💖

Again, for the people in the back: got fetch will refuse to fetch references from the remote repository's refs/remotes/ or refs/got/ namespace. Periodt. 🚫

-r repository-path — Use the repository at the specified path. If you don't specify it, assume the repository is located at or above the current working directory. And if this directory is a got work tree, use the repository path associated with this work tree. She'll find it, don't worry 🧚
-t — Allow existing references in the refs/tags namespace to be updated if they've changed on the server. If you don't specify this, only new tag references get created. So like, tags are sacred by default 😌🏷️
-v — Verbose mode. Causes got fetch to print debugging messages to standard error output. If applicable, the same option gets passed to ssh(1). Multiple -v options increase the verbosity. The maximum is 3. (Yes, still 3. Still the limit. Still the vibe.) 🔥
-X — Delete all references which correspond to a particular remote-repository instead of fetching new changes. This is useful when a remote repository is being removed from got.conf(5) — clean exit, no crumbs 💅

With -X, the remote-repository argument is mandatory and no other options except -r, -v, and -q are allowed. Read that again bestie, that's a strict door policy 🚪

Only references get deleted. Any commit, tree, tag, and blob objects fetched from a remote repository will generally be stored in pack files and may be removed separately with gotadmin cleanup and Git's garbage collector.

✨ checkout ✨ (alias: `co`)

checkout [-Eq] [-b branch] [-c commit] [-p path-prefix] repository-path
          [work-tree-path]

Copy files from a repository into a brand new work tree 🌸 The moment of manifestation. It shows the status of each affected file, using these status codes:

A — new file was added 🎉
E — file already exists in work tree's meta-data 👀
? — file with a path outside of the work tree was skipped 🙈

If the work tree path isn't specified, it either uses the last component of repository path, or — if a path prefix was specified — it uses the last component of path prefix. Adaptive queen ✨

The options for got checkout are as follows:

-b branch — Check out files from a commit on the specified branch. If you don't specify this option, a branch resolved via the repository's HEAD reference gets used. Let HEAD decide, she knows 🫶
-c commit — Check out files from the specified commit on the selected branch. If this option isn't specified, the most recent commit on the selected branch gets used. Fresh off the press 💖

The whole commit-argument situation, bestie, is this: you hand it a commit ID, or a reference name, or a keyword, and it gets resolved into an actual commit ID for you. An abbreviated hash? It expands to the full commit ID automatically — as long as that abbreviation is unique, no cap. The keywords :base and :head resolve to the repository's HEAD reference, or, if the -b option is used, to the head of the checked-out branch.

And then there's the modifier magic ✨ — keywords and reference names can be followed by :+ or :- modifiers with an optional integer N, which means "the Nth descendant" or "the Nth antecedent" respectively, by first-parent traversal. So :head:-2 is the work tree branch head's 2nd generation ancestor, and foo:-3 is the 3rd generation ancestor of whatever commit the foo reference resolves to. If you're chaotic and just don't write a number after :+ or :-, a 1 gets implicitly appended — like :head:- is literally the same thing as :head:-1. Cute, right? 🎀

Okay but here's the vibe check that matters: if the commit you specified is not contained in the selected branch, then a different branch which contains this commit has to be named with the -b option. And if no such branch exists? You gotta make one with got branch for this commit before got checkout will even look at you. Checking out work trees with an unknown branch is intentionally not supported. It's giving boundaries. 💅

-E — Proceed with the checkout operation even if the directory at work-tree-path is not empty. Existing files stay exactly where they are, left intact. 🫶
-p path-prefix — Restrict the work tree to a subset of the repository's tree hierarchy. Only files beneath the specified path-prefix get checked out. 🌸
-q — Silence progress output. For when you want peace and quiet. 🤫

🌈 update

update [-q] [-b branch] [-c commit] [path ...]
                (alias: up)

Update an existing work tree to a different commit. Existing files in the work tree get changed as necessary to match the file contents of that commit. And crucially — your local changes are preserved and merged with the incoming changes. She's considerate like that. 💖

Files which already contain merge conflicts will not be updated, to avoid further complications. 🙈 Such files get updated when got update is run again after the merge conflicts have been resolved. If you don't need those conflicting changes anymore, you can revert the affected files with got revert before running got update again.

Show the status of each affected file, using these status codes:

U — file was updated and contained no local changes
G — file was updated and local changes were merged cleanly
C — file was updated and conflicts occurred during merge
D — file was deleted
d — file's deletion was prevented by local modifications
A — new file was added
~ — versioned file is obstructed by a non-regular file
! — a missing versioned file was restored
# — file was not updated because it contains merge conflicts
? — changes destined for an unversioned file were not merged

If no path is specified, update the entire work tree. Otherwise, restrict the update operation to files at or within the specified paths. Each path is required to exist in the update operation's target commit. 🧚 Files in the work tree outside the specified paths will remain unchanged and will retain their previously recorded base commit. And heads up — some got commands may straight up refuse to run while the work tree contains files from multiple base commits. The base commit of such a work tree can be made consistent by running got update across the entire work tree. Specifying a path is incompatible with the -b option, okay?

got update cannot update paths with staged changes. If changes have been staged with got stage, those changes must first be committed with got commit or unstaged with got unstage. No skipping steps, bestie. 😭

The options for got update are as follows:

-b branch — Switch the work tree's branch reference to the specified branch before updating the work tree. This option requires that all paths in the work tree are updated.

As usual, any local changes in the work tree will be preserved. This can be useful when switching to a newly created branch in order to commit existing local changes to this branch. 🌿

Any local changes must be dealt with separately if you want a work tree with pristine file contents corresponding exactly to the specified branch. Such changes could first be committed to a different branch with got commit, or could be discarded with got revert.

-c commit — Update the work tree to the specified commit. If this option isn't specified, the most recent commit on the work tree's branch will be used.

The expected commit argument is a commit ID, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full commit ID automatically, provided the abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. Keywords and reference names may be appended with :+ or :- modifiers and an optional integer N to denote the Nth descendant or antecedent, respectively, by first parent traversal; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, foo:-3 will denote the 3rd generation ancestor of the commit resolved by the "foo" reference. If an integer does not follow the :+ or :- modifier, a "1" is implicitly appended (e.g., :head:- is equivalent to :head:-1).

-q — Silence progress output. 🤐

💜 status

status [-I] [-S status-codes] [-s status-codes] [path ...]
                (alias: st)

Show the current modification status of files in a work tree, using these status codes:

M — modified file
A — file scheduled for addition in next commit
D — file scheduled for deletion in next commit
C — modified or added file which contains merge conflicts
! — versioned file was expected on disk but is missing
~ — versioned file is obstructed by a non-regular file
? — unversioned item not tracked by got
m — modified file modes (executable bit only)
N — non-existent path specified on the command line

If no path is specified, show modifications in the entire work tree. Otherwise, show modifications at or within the specified paths. 🦋

If changes have been staged with got stage, staged changes are shown in the second output column, using these status codes:

M — file modification is staged
A — file addition is staged
D — file deletion is staged

Changes created on top of staged changes are indicated in the first column:

MM — file was modified after earlier changes have been staged
MA — file was modified after having been staged for addition

If the work tree contains the results of an interrupted got rebase, got histedit, or got merge operation, then a message is displayed showing the branches involved. 👀

The options for got status are as follows:

-I — Show unversioned files even if they match an ignore pattern. See “Ignore Patterns”. 🙈
-S status-codes — Suppress the output of files with a modification status matching any of the single-character status codes contained in the status-codes argument. Any combination of codes from the above list of possible status codes may be specified. For staged files, status codes displayed in either column will be matched. Cannot be used together with the -s option.
-s status-codes — Only show files with a modification status matching any of the single-character status codes contained in the status-codes argument. Any combination of codes from the above list of possible status codes may be specified. For staged files, status codes displayed in either column will be matched. Cannot be used together with the -S option.

⭐ log

log [-bdPpRst] [-C number] [-c commit] [-l N] [-r repository-path]
    [-S search-pattern] [-x commit] [path]

Display the history of a repository. 📜 If a path is specified, show only commits which modified this path. If invoked in a work tree, the path is interpreted relative to the current working directory, and the work tree's path prefix is implicitly prepended. Otherwise, the path is interpreted relative to the repository root.

The options for got log are as follows:

-b — Display individual commits which were merged into the current branch from other branches. By default, got log shows the linear history of the current branch only. ✨
-C number — sets how many context lines get shown in the diffs that -p spits out. Bestie, it's 3 lines by default, that's the vibe. 💅
-c commit — start walking the history from this exact commit, okay? If you don't pass it, it just defaults to the work tree's current branch (when you're in a work tree) or the repository's HEAD reference. Classic.

So what even counts as a commit argument? Any of these, bestie: a commit ID, a reference name, or a keyword — all of which get resolved into a commit ID. And if you hand over an abbreviated hash, it'll get expanded to the full commit ID automatically, but only if the abbreviation is unique. No duplicates allowed, she's picky.

Now the keywords. :base and :head resolve to the work tree's base commit and branch head, respectively. :base is only valid if you're invoked in a work tree. :head is flexible like that — it resolves to the tip of the work tree's current branch if you're in a work tree, otherwise it resolves to the repository's HEAD reference. 👑

And here's where it gets iconic: keywords and references can be appended with :+ or :- modifiers plus an optional integer N, to denote the N-th descendant or antecedent respectively — by first parent traversal. For example, :head:-2 denotes the HEAD reference's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, bar:+3 will denote the 3rd generation descendant of the commit resolved by the "bar" reference. And if you leave the integer off? A :+ or :- modifier without a trailing integer has an implicit 1 appended (e.g., :base:+ is equivalent to :base:+1). The way she just knows what you meant. 🧚

-d — display diffstat of the changes introduced in each commit. Cannot be used with -s, and it implies the -P option (because diffstat displays a list of changed paths). Cute combo, honestly.
-l N — cap how far history traversal goes, by number of commits. If you don't set it, the default limit value is zero, which gets treated as an unbounded limit. And yeah, the GOT_LOG_DEFAULT_LIMIT environment variable may be set to change that default value. 🌈
-P — show the list of file paths changed in each commit, using these status codes, bestie:
- M — modified file
- D — file was deleted
- A — new file was added
- m — modified file modes (executable bit only)

Cannot be used with the -s option. They are NOT friends.

-p — display the patch of modifications made in each commit. If a path is specified, only show the patch of modifications at or within this path. Cannot be used with the -s option either. 😭
-R — determine a set of commits to display as usual, but display these commits in reverse order. Same commits, backwards energy. Time travel but make it editorial.
-r repository-path — use the repository at the specified path. If you don't specify it, it assumes the repository is located at or above the current working directory. And if this directory happens to be a got work tree, it uses the repository path associated with this work tree. 🫶
-S search-pattern — if specified, only show commits with a log message, author name, committer name, or commit ID matched by the extended regular expression search-pattern. Lines in committed patches will be matched if -p is specified. File paths changed by a commit will be matched if -P is specified. And the regular expression syntax is documented over in re_format(7), iykyk. 🔍
-s — display a short one-line summary of each commit, instead of the default history format. Cannot be used together with the -p or -P option. Pick a lane, gorgeous.
-t — display commits in topological order. This option has no effect without the -b option, because a linear history is sorted in topological order by definition. Topological sorting is disabled by default because the present implementation requires that commit history is fully traversed before any output can be shown. Heavy. Costs. Periodt.
-x commit — stop traversing commit history immediately after the specified commit has been traversed. Just like -c, the expected commit argument is a commit ID, or a reference name or a keyword which will be resolved to a commit ID. This option has no effect if the specified commit is never traversed. 🙈

🦋 `got diff` 🦋

diff [-adPsw] [-C number] [-c commit] [-r repository-path] [object1
     object2 | path ...]
       (alias: di)

Okay so! When you invoke diff inside a work tree with no arguments at all, it displays all local changes in the work tree. Give it one or more path arguments and it only shows changes within the specified paths. Simple, slay.

If you hand it two arguments, it treats each one as a reference, a tag name, or an object ID, and displays the differences between the corresponding objects. Both objects have to be of the same type (blobs, trees, or commits). An abbreviated hash argument gets expanded to a full commit ID automatically, provided the abbreviation is unique. And if none of those interpretations produce a valid result — or if the -P option is used — and got diff is running in a work tree, it'll attempt to interpret the two arguments as paths. She adapts. That's her superpower.

The options for got diff are as follows:

-a — treat file contents as ASCII text even if binary data is detected. 💅
-C number — set the number of context lines shown in the diff. By default, 3 lines of context are shown. 🎀
-c commit — show differences between commits in the repository. This option may be used up to two times. When used only once, show differences between the specified commit and its first parent commit. When used twice, show differences between the two specified commits. Twice the -c, twice the drama.

If the -c option is used, all non-option arguments will be interpreted as paths. If one or more such path arguments are provided, only show differences for the specified paths.

The expected commit argument is a commit ID, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full commit ID automatically, provided the abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and references may be appended with :+ or :- modifiers and an optional integer N to denote the N-th descendant or antecedent, respectively, by first parent traversal; for example, :head:-2 denotes the HEAD reference's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, baz:+8 will denote the 8th generation descendant of the commit resolved by the "baz" reference. If an integer does not follow the :+ or :- modifier, a 1 is implicitly appended (e.g., :head:- is equivalent to :head:-1). 🧚

Cannot be used together with the -P option. Do not try it, bestie.

-d — display diffstat of changes before the actual diff, by annotating each file path or blob hash being diffed with the total number of lines added and removed. A summary line will display the total number of changes across all files. ⭐
-P — interpret all arguments as paths only. This option can be used to resolve ambiguity in cases where paths look like tag names, reference names, or object IDs. This option is only valid when got diff is invoked in a work tree. Gaslight-proof those path names, queen.
-r repository-path — use the repository at the specified path. If not specified, assume the repository is located at or above the current working directory. If this directory is a got work tree, use the repository path associated with this work tree. 💜
-s — show changes staged with got stage instead of showing local changes in the work tree. This option is only valid when got diff is invoked in a work tree. 🌸
-w — ignore whitespace-only changes. Whitespace? Never heard of her.

👑 `got blame` 👑

blame [-c commit] [-r repository-path] path
       (alias: bl)

Display line-by-line history of a file at the specified path. The receipts. For every. single. line. 💅

The options for got blame are as follows:

-c commit — start your history stroll at this specific commit, bestie 💫 the arg you hand over is a commit ID, or a reference name, or one of the magic keywords, and it all gets resolved down to a commit ID for you. An abbreviated hash gets auto-expanded into a full commit ID, provided the abbreviation is unique (so don't be cute with a two-char hash and expect a miracle 🙈). The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. :base is only valid if you're invoked inside a work tree, and :head resolves to the tip of the work tree's current branch when you're in a work tree — otherwise it falls back to the repository's HEAD reference. Keywords and references can be tacked onto with :+ or :- modifiers plus an optional integer N, meaning the *N*th descendant or the *N*th antecedent by first parent traversal, respectively (descendants forward, ancestors backward, iykyk). So like, :head:-2 is the work tree branch head's 2nd generation ancestor, and :base:+4 is the 4th generation descendant of the work tree's base commit. Same energy: xyz:-5 means the 5th generation ancestor of the commit resolved by the xyz reference. And if you leave off the trailing integer, a :+ or :- modifier has an implicit 1 appended (e.g. :base:+ is equivalent to :base:+1). Slay. ✨
-r repository-path — point at the repo living at this path 🫶 if you don't specify it, we assume the repository is located at or above the current working directory. And if this directory happens to be a got work tree? Then we use the repository path associated with this work tree. no cap.

🌳 `tree` — aka `tr` 🌳

tree [-iR] [-c commit] [-r repository-path] [path]

(alias: tr)

Okay so got tree is literally just showing you a listing of the files and directories at the specified directory path in the repository 🎀 a whole vibe check of your tree. Entries in this listing might carry one of these trailing annotations:

@ — entry is a symbolic link
/ — entry is a directory
* — entry is an executable file
$ — entry is a Git submodule

Symbolic link entries also get annotated with the target path of the link 👑 (thoughtful, honestly).

If you don't pass a path, it lists the repository path corresponding to the current directory of the work tree — or the root directory of the repository if there's no work tree at all. Either way, covered 💅

The options for got tree are as follows:

-c commit — list files and directories as they appear in the specified commit. So like, the tree at that moment in time.

The expected argument is a commit ID, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full commit ID automatically, provided the abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and references may be appended with :+ or :- modifiers and an optional integer N to denote the *N*th descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, spam:-3 will denote the 3rd generation ancestor of the commit resolved by the spam reference. A :+ or :- modifier without a trailing integer has an implicit 1 appended (e.g., :base:+ is equivalent to :base:+1).

-i — show object IDs of files (blob objects) and directories (tree objects) 🔍 the receipts, basically.
-R — recurse into sub-directories in the repository. Go deeper. 🌀
-r repository-path — use the repository at the specified path. If not specified, assume the repository is located at or above the current working directory. If this directory is a got work tree, use the repository path associated with this work tree.

🎀 `ref` 🎀

ref [-dlt] [-c object] [-r repository-path] [-s reference] [name]

Manage references in a repository 💖 references can be listed, created, deleted, and changed — the full glow-up pipeline. When you're creating, deleting, or changing a reference, the specified name must be an absolute reference name, i.e. it must begin with “refs/”. Non-negotiable, bestie.

The options for got ref are as follows:

-c object — create a reference or change an existing reference. The reference with the specified name will point at the specified object. Iconic, honestly.

The expected object argument is an object ID or an existing reference or tag name or a keyword which will be resolved to the ID of a corresponding commit, tree, tag, or blob object. An abbreviated hash argument will be expanded to a full commit ID automatically, provided the abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and reference names may be appended with :+ or :- modifiers and an optional integer N to denote the *N*th descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and tagged:-3 will denote the 3rd generation ancestor of the commit resolved by the tagged reference. If an integer does not follow the :+ or :- modifier, a 1 is implicitly appended (e.g., :head:- is equivalent to :head:-1).

Cannot be used together with any other options except -r. So don't try to stack it, fr fr 😭

-d — delete the reference with the specified name from the repository. Heads up though: any commit, tree, tag, and blob objects belonging to deleted references remain in the repository, and may be removed separately with Git's garbage collector or gotadmin cleanup. So like, deleting the ref doesn't delete the stuff 💀 it just unhooks it.

Cannot be used together with any other options except -r.

-l — list references in the repository. If no name is specified, list all existing references in the repository. If name is a reference namespace, list all references in this namespace. Otherwise, show only the reference with the given name. The librarian energy 📚

Cannot be used together with any other options except -r and -t.

-r repository-path — use the repository at the specified path. If not specified, assume the repository is located at or above the current working directory. If this directory is a got work tree, use the repository path associated with this work tree.
-s reference — create a symbolic reference, or change an existing symbolic reference. The symbolic reference with the specified name will point at the specified reference, which must already exist in the repository 🌸 care should be taken not to create loops between references when this option is used. Like, loops are the enemy, bestie. Don't do it.

Cannot be used together with any other options except -r.

-t — sort listed references by modification time (most recently modified first) instead of sorting by lexicographical order. Use of this option requires the -l option to be used as well. Freshest first, we love a chronological queen ⏰

🦋 `branch` — aka `br` 🦋

branch [-lnt] [-c commit] [-d name] [-r repository-path] [name]

(alias: br)

Create, list, or delete branches ✨

Local branches are managed via references which live in the “refs/heads/” reference namespace. The got branch command creates references in this namespace only. That's the whole assignment.

When deleting branches, the specified name is searched in the “refs/heads” reference namespace first. If no corresponding branch is found, the “refs/remotes” namespace will be searched next. Look everywhere, basically 🙈

If invoked in a work tree without any arguments, print the name of the work tree's current branch 🫶 (your main character moment, named).

If a name argument is passed, attempt to create a branch reference with the given name. By default the new branch reference will point at the latest commit on the work tree's current branch if invoked in a work tree, and otherwise to a commit resolved via the repository's HEAD reference.

If invoked in a work tree, once the branch was created successfully, switch the work tree's head reference to the newly created branch and update files across the entire work tree, just like got update -b name would do. Show the status of each affected file, using the following status codes:

U — file was updated and contained no local changes ✨
G — file was updated and local changes were merged cleanly 🫶
C — file was updated and conflicts occurred during merge 😭
D — file was deleted 💀
A — new file was added 🎀
~ — versioned file is obstructed by a non-regular file 🙈
! — a missing versioned file was restored 🌈

✨ the options for `got branch`, bestie ✨

-c commit — makes a newly created branch reference point at the commit you name. What you pass is a commit ID, or a reference name, or a keyword, and it gets resolved into a commit ID. An abbreviated hash gets expanded into the full commit ID automatically, as long as that abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively — the first one is only valid if you're invoked in a work tree, while the second resolves to the tip of the work tree's current branch if you're in a work tree, and otherwise resolves to the repository's HEAD reference. Keywords and references can be suffixed with :+ or :- modifiers plus an optional integer N, meaning the *N*th descendant or antecedent by first parent traversal, respectively. So :head:-2 is the work tree branch head's 2nd generation ancestor, and :base:+4 is the 4th generation descendant of the work tree's base commit. Same energy: foobar:+3 means the 3rd generation descendant of the commit that the foobar reference resolves to. And a :+ or :- with no trailing integer secretly has an implicit "1" appended (so :base:+ is literally the same as :base:+1). 💅
-d name — deletes the branch with that name from the “refs/heads” or “refs/remotes” reference namespace. Only the branch reference goes away. Any commit, tree, and blob objects that belonged to the branch stay in the repository, and you can remove them separately with Git's garbage collector or gotadmin cleanup.
-l — lists all existing branches in the repository, and yes that includes copies of remote repositories' branches living in the “refs/remotes/” reference namespace. If you're in a work tree, the work tree's current branch gets shown with one of these annotations:
- * — the work tree's base commit and the base commit of all tracked files matches the branch tip
- ~ — the work tree comprises mixed commits or its base commit is out-of-date
-n — do not switch and update the work tree after creating a new branch. no chaos, no moving, just vibes ✋
-r repository-path — use the repository at the path you give. If you don't specify one, it assumes the repository is at or above the current working directory. And if this directory is a got work tree, it uses the repository path associated with that work tree.
-t — sorts listed branches by modification time (most recently modified first) instead of lexicographical order. Branches in the “refs/heads/” reference namespace get listed before branches in “refs/remotes/” no matter what. Heads up bestie: using this option requires the -l option to be used as well.

🏷️ `tag`

tag [-lsVv] [-c commit] [-m message] [-r repository-path] [-S signer-id]
    name

Manage tags in a repository. Tags live as references inside the “refs/tags/” reference namespace, and got tag only ever operates on references in that namespace — it doesn't wander off 👀. References in this namespace point at tag objects, and a tag object contains a pointer to another object, a tag message, plus author and timestamp info.

So it tries to create a tag with the given name, pointing at the given commit. If you don't specify a commit, it defaults to the latest commit on the work tree's current branch when invoked in a work tree, and to a commit resolved via the repository's HEAD reference otherwise.

the options for `got tag` 💖

-c commit — makes the newly created tag reference point at the commit you name. The expected commit argument is a commit ID, or a reference or keyword that resolves to a commit ID. An abbreviated hash argument gets expanded to a full commit ID automatically, provided the abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively — the former is only valid if invoked in a work tree, while the latter resolves to the tip of the work tree's current branch if invoked in a work tree, and otherwise resolves to the repository's HEAD reference. Keywords and references may be appended with :+ or :- modifiers and an optional integer N, denoting the *N*th descendant or antecedent by first parent traversal, respectively. Example time: :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, eggs:-3 denotes the 3rd generation ancestor of the commit resolved by the "eggs" reference. And a :+ or :- modifier with no trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1). slay. ✨
-l — lists all existing tags in the repository instead of creating a new tag. If you pass a name argument, it shows only the tag with that name. 🎀
-m message — uses the message you give as the new tag's tag message. Without -m, got tag opens a temporary file in an editor so you can write one. And if you quit the editor without saving the file, the tag operation aborts. no half-tags, periodt.
-r repository-path — use the repository at the specified path. If not specified, assume the repository is located at or above the current working directory. If this directory is a got work tree, use the repository path associated with this work tree.
-S signer-id — while creating a new tag, sign this tag with the identity given in signer-id. For SSH-based signatures, signer-id is the path to a file which may refer to either a private SSH key, or a public SSH key with the private half available via ssh-agent(1). got tag signs the tag object by invoking ssh-keygen(1) with the -Y sign command, using the signature namespace “git” for compatibility with git(1).
-s — displays a short one-line summary of each tag instead of the default history format. Can only be used with the -l option. ✋ don't try it solo.
-V — verifies tag object signatures. If a name is specified, it shows and verifies the tag object with that name. Otherwise it lists all tag objects and verifies signatures where present. got tag verifies SSH-based signatures by invoking ssh-keygen(1) with the options -Y verify -f allowed_signers. A path to the allowed_signers file must be set in got.conf(5), otherwise verification is impossible. 😭
-v — verbose mode. During SSH signature creation and verification this option gets passed to ssh-keygen(1). Multiple -v options increase the verbosity. The maximum is 3.

By design, the got tag command will not delete tags or change existing tags. If a tag must be deleted, the got ref command may be used to delete a tag's reference. This should only be done if the tag has not already been copied to another repository. 👑

➕ `add`

add [-IR] path ...

Schedules unversioned files in a work tree for addition to the repository in the next commit. By default, files matching an ignore pattern will not be added — see “Ignore Patterns” below. 🦋

If a path on the command line isn't an unversioned file, got add may raise an error. And to save you from pointless errors caused by paths picked up by file globbing patterns in the shell, paths in the argument list get silently ignored if got status doesn't report them at all, or if they're reported with one of these status codes and don't have changes staged via got stage:

M — modified file
A — file scheduled for addition in next commit
C — modified or added file which contains merge conflicts
m — modified file modes (executable bit only)

the options for `got add` 🌸

-I — add files even if they match an ignore pattern. See “Ignore Patterns”. 💅
-R — permit recursion into directories. If this option is not specified, got add will refuse to run if a specified path is a directory.

🗑️ `got remove` (aka `rm`) — time to say bye bestie 💅

remove [-fkR] [-s status-codes] path ...
                (alias: rm)

So this one literally removes versioned files from your work tree and schedules them for deletion from the repo in the next commit. It's not an instantly-gone situation, it's a "noted, you're on the list" situation. 👑

The options for got remove are as follows:

-f — do the thing anyway, even if the file has local modifications, and don't throw an error if a path you named doesn't actually exist on disk. She's forgiving like that. 🫶
-k — keep the affected files on disk. So the repo forgets them but your filesystem does not. best of both worlds honestly ✨
-R — permit recursion into directories. And pls note: if you don't pass this, got remove will straight up refuse to run if any path you gave is a directory. no 🚫
-s status-codes — only delete files whose modification status matches one of the single-character status codes you put in the status-codes argument. The valid codes are:
- M — modified file (heads up: this implies the -f option)
- ! — versioned file that's expected on disk but is missing

🩹 `got patch` (aka `pa`) — glow-up via diff 🌈

patch [-nR] [-c commit] [-p strip-count] [patchfile]
                (alias: pa)

This applies changes from patchfile onto the files in your work tree. Files that a patch adds or removes get scheduled for addition or removal in the work tree. cute.

The patch has got to be in the unified diff format, like the stuff produced by got diff, git-diff(1), or by diff(1) and cvs(1) diff when you invoke them with their -u options. And if you don't hand over a patchfile argument at all? No worries, she'll read unified diff data from standard input instead. 🎀

If the patchfile has multiple patches in it, she attempts to apply each one in sequence. one at a time, calm and collected.

She shows you the status of each affected file, using these codes:

M — file was modified
G — file was merged using a merge-base found in the repository
C — file was merged and conflicts occurred during merge
D — file was deleted
A — file was added
# — failed to patch the file 😭

If a change doesn't match at its exact line number, she'll try to apply it somewhere else in the file if a good spot can be found. Otherwise? The patch just fails to apply. rip. 💀

Now the preconditions, and bestie she is strict:

got patch will refuse to apply a patch if certain preconditions are not met. Files to be deleted must already be under version control, and must not have been scheduled for deletion already. Files to be added must not yet be under version control and must not already be present on disk. Files to be modified must already be under version control and may not contain conflict markers.

If an error occurs, the patch operation will be aborted. Any changes made to the work tree up to that point will be left behind. You can look at them with got diff and undo them with got revert if you need to. 🚨

The options for got patch are as follows:

-c commit — try to locate files inside the specified commit to use as a merge-base for 3-way merges. If you don't use -c, then got patch will try to find merge-bases via object IDs found in patchfile meta-data, like the stuff produced by got diff or git-diff(1). And heads up: using -c is only recommended when that meta-data isn't there. Ideally, the commit you specify should contain versions of the files that the changes in the patchfile were based on. Files get located by path, relative to the repository root. If the -p option is used then leading path components get stripped before the paths are looked up in the repository. In case there's no merge-base available for a file, changes get applied without doing a 3-way merge. And then changes that don't apply cleanly may get rejected entirely, instead of producing merge conflicts in the patched target file. The expected commit argument is a commit ID, or a reference name, or a keyword that resolves to a commit ID. An abbreviated hash argument gets expanded to a full commit ID automatically, as long as the abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. Keywords and references may be appended with :+ or :- modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, flan:+3 denotes the 3rd generation descendant of the commit resolved by the "flan" reference. A :+ or :- modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1). iykyk 🧚
-n — make zero modifications to the work tree. Perfect for vibe-checking whether a patch would apply without issues. ⚠️ but lowkey a warning: if the patchfile contains diffs that affect the same file multiple times, the results displayed may be incorrect. noted.
-p strip-count — specify how many leading path components to strip from paths parsed out of patchfile. If you don't use -p, the ‘a/’ and ‘b/’ path prefixes generated by git-diff(1) get recognized and stripped automatically. she's helpful like that 💖
-R — reverse the patch before applying it. uno reverse card 🃏

↩️ `got revert` (aka `rv`) — the undo button, no takebacks

revert [-pR] [-F response-script] path ...
                (alias: rv)

Reverts any local changes in the files at the specified paths in a work tree. File contents get overwritten with whatever's in the work tree's base commit.

There is NO WAY to bring discarded changes back after got revert! 😭 This is the realest it gets, bestie. Double check before you commit to it.

Fun facts tho:

If a file was added with got add, it becomes an unversioned file again.
If a file was deleted with got remove, it gets restored. ✨

The options for got revert are as follows:

-F response-script — with the -p option, read “y”, “n”, and “q” responses line-by-line from the specified response-script file instead of prompting you interactively. automation queen 👑
-p — instead of reverting all changes in files, interactively pick or reject changes to revert based on “y” (revert change), “n” (keep change), and “q” (quit reverting this file) responses. If a file is in modified status, individual patches derived from the modified file content can be reverted. Files in added or deleted status may only be reverted in their entirety. no cherry-picking those, sorry 🍒
-R — permit recursion into directories. If you don't specify this, got revert will refuse to run if a specified path is a directory. same energy as remove, she's consistent 💅

📝 `got commit` (aka `ci`) — the main character moment 🎬

commit [-CNnS] [-A author] [-F path] [-m message] [path ...]
                (alias: ci)

Creates a new commit in the repository from the changes in a work tree, and uses that commit as the new base commit for the work tree. If no path is specified, it commits all changes in the work tree. Otherwise, it commits changes at or within the specified paths.

If changes have been explicitly staged for commit with got stage, it only commits the staged changes and rejects any specified paths which have not been staged. staged means staged, periodt. 💯

got commit opens a temporary file in an editor where you write the log message — unless you use the -m option, or you use the -F and -N options together. And if you quit the editor without saving the file? The commit operation is aborted. bye 👋

It shows the status of each affected file, using these status codes:

M — modified file
D — file was deleted
A — new file was added
m — modified file modes (executable bit only)

Files that aren't part of the new commit keep their previously recorded base commit. Heads up: some got commands may refuse to run while the work tree contains files from multiple base commits. The base commit of a work tree like that can be made consistent by running got update across the entire work tree. 🧹

And now, the info you need: the got commit command requires the GOT_AUTHOR environment variable to be set — unless an author has been configured in got.conf(5), or Git's user.name and user.email configuration settings can be obtained from the repository's .git/config file or from Git's global ~/.gitconfig configuration file. so many fallbacks, one of them will catch you 🫶

The options for got commit are as follows:

-A author — set the author information in the newly created commit to author. Super useful when you're committing changes on behalf of someone else. And the author argument has to use the same format as the GOT_AUTHOR environment variable. ngl the format matters, don't freestyle it. ✨ In addition to storing author information, the newly created commit object will retain “committer” information which is obtained, as usual, from the GOT_AUTHOR environment variable, or got.conf(5), or Git configuration settings.
-C — allow committing files in conflicted status. yes, even those files. brave of you fr fr 🫡

like, real talk before we even touch the flags: committing files that still have conflict markers in them? please don't 🙈. those cases where conflict markers have to live in the repo for some legit reason are genuinely super rare, and there's usually a way to dodge storing them verbatim by applying the right programming trick ✨

-F path — use the prepared log message saved in the file at path when creating the new commit. got commit still opens a temporary file in an editor so you can review that prepared message and keep editing it if you want. ⚠️ cannot be used together with the -m option.
-m message — just hand over the log message directly when creating the new commit. ⚠️ cannot be used together with the -F option.
-N — stops got commit from opening the commit message in an editor. heads up tho: it does nothing unless you use it together with the -F option, and it exists for non-interactive vibes like scripting.
-n — stops got commit from generating a diff of the to-be-committed changes in a temporary file. normally you'd get to peek at that while editing a commit message, and this kills that.
-S — allow the addition of symbolic links that point outside of the path space that's under version control. by default got commit rejects those bad boys due to safety concerns 🛡️. as a precaution, got may decide to represent such a symbolic link as a regular file containing the link's target path, rather than creating an actual symbolic link which points outside of the work tree. use of this option is discouraged because external mechanisms such as "make obj" are better suited for managing symbolic links to paths not under version control.

got commit will refuse to run if certain preconditions are not met. if the work tree's current branch is not in the refs/heads/ reference namespace, new commits may not be created on this branch. local changes may only be committed if they are based on file content found in the most recent commit on the work tree's branch. and if a path is found to be out of date, got update must be used first in order to merge local changes with changes made in the repository.

✨ send ✨

send [-afqTv] [-b branch] [-d branch] [-i identity-file] [-J jumphost]
          [-r repository-path] [-t tag] [remote-repository]
                (alias: se)

Send new changes to a remote repository 💌. if no remote-repository is specified, origin will be used. the remote repository's URL comes from the corresponding entry in got.conf(5) or Git's config file of the local repository, as created by got clone.

All objects corresponding to new changes get written to a temporary pack file, and that pack file is then uploaded to the server. upon success, references in the refs/remotes/ reference namespace of the local repository will be updated to point at the commits which have been sent 🎯.

By default, changes will only be sent if they're based on up-to-date copies of relevant branches in the remote repository. if any changes to be sent are based on out-of-date copies, or would otherwise break linear history of existing branches, new changes must be fetched from the server with got fetch and local branches must be rebased with got rebase before got send can succeed. the -f option can be used to make exceptions to these requirements 👀.

The options for got send are as follows:

-a — send all branches from the local repository's refs/heads/ reference namespace. -a is equivalent to listing all branches with multiple -b options. ⚠️ cannot be used together with the -b option.
-b branch — send the specified branch from the local repository's refs/heads/ reference namespace. this option may be specified multiple times to build a list of branches to send 🌈. if this option is not specified, it defaults to the work tree's current branch if invoked in a work tree, or to the repository's HEAD reference. ⚠️ cannot be used together with the -a option.
-d branch — delete the specified branch from the remote repository's refs/heads/ reference namespace. may be specified multiple times to build a list of branches to delete 🗑️.

Only references are deleted. any commit, tree, tag, and blob objects belonging to deleted branches may become subject to deletion by Git's garbage collector running on the server. 💀

Requesting deletion of branches results in an error if the server does not support this feature or disallows the deletion of branches based on its configuration.

-f — attempt to force the server to overwrite existing branches or tags in the remote repository, even when got fetch followed by got rebase or got merge would usually be required before changes can be sent. the server may reject forced requests regardless, depending on its configuration.

Any commit, tree, tag, and blob objects belonging to overwritten branches or tags may become subject to deletion by Git's garbage collector running on the server. 💀

The refs/tags reference namespace is globally shared between all repositories. use of the -f option to overwrite tags is discouraged because it can lead to inconsistencies between the tags present in different repositories 😭. in general, creating a new tag with a different name is recommended instead of overwriting an existing tag.

Use of the -f option is particularly discouraged if changes being sent are based on an out-of-date copy of a branch in the remote repository. instead of using -f, new changes should be fetched with got fetch and local branches should be rebased with got rebase or merged with got merge, followed by another attempt to send the changes.

The -f option should only be needed in situations where the remote repository's copy of a branch or tag is known to be out-of-date and is considered disposable. the risks of creating inconsistencies between different repositories should also be taken into account 🫶.

-i identity-file — specify an identity-file, containing a private SSH key, to use with SSH connections 🔑. the same option will be passed to ssh(1).
-J jumphost — specify a jumphost to use with SSH connections 🚪. the same option will be passed to ssh(1).
-q — suppress progress reporting output. the same option will be passed to ssh(1) if applicable 🤫.
-r repository-path — use the repository at the specified path. if not specified, assume the repository is located at or above the current working directory. if this directory is a got work tree, use the repository path associated with this work tree.
-T — attempt to send all tags from the local repository's refs/tags/ reference namespace 🏷️. -T is equivalent to listing all tags with multiple -t options. ⚠️ cannot be used together with the -t option.
-t tag — send the specified tag from the local repository's refs/tags/ reference namespace, in addition to any branches that are being sent. may be specified multiple times to build a list of tags to send. no tags will be sent if the -t option is not used.

Raise an error if the specified tag already exists in the remote repository, unless the -f option is used to overwrite the server's copy of the tag. in general, creating a new tag with a different name is recommended instead of overwriting an existing tag.

⚠️ cannot be used together with the -T option.

-v — verbose mode. causes got send to print debugging messages to standard error output 🐛. the same option will be passed to ssh(1) if applicable. multiple -v options increase the verbosity. the maximum is 3.

✨ cherrypick ✨

cherrypick [-lX] [commit]
                (alias: cy)

Merge changes from a single commit into the work tree 🍒. the specified commit should be on a different branch than the work tree's base commit.

The expected argument is a commit ID, or a reference name or keyword that gets resolved into a commit ID. ✨ If you hand it an abbreviated hash, it'll get expanded into a full commit ID all by itself — as long as that abbreviation is actually unique, bestie. No cap.

The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. And you can append keywords and references with :+ or :- modifiers plus an optional integer N to mean the *N*th descendant or antecedent by first-parent traversal. Like, :head:-2 is the work tree branch head's 2nd generation ancestor, and :base:+4 is the 4th generation descendant of the work tree's base commit. Same energy: barbaz:+3 is the 3rd generation descendant of whatever commit the "barbaz" reference resolves to. And a :+ or :- modifier with no trailing integer just gets an implicit "1" appended (so :base:+ is literally :base:+1, periodt).

It'll show you the status of every affected file using these status codes:

G      file was merged
C      file was merged and conflicts occurred during merge
!      changes destined for a missing file were not merged
D      file was deleted
d      file's deletion was prevented by local modifications
A      new file was added
~      changes destined for a non-regular file were not merged
?      changes destined for an unversioned file were not merged

The merged changes show up as local changes in the work tree, which you can peek at with got diff, amend by hand or with more got cherrypick commands, and commit with got commit. 💅

If you run this in a work tree where no rebase, histedit, or merge operation is happening, got cherrypick creates a record of commits which have been merged into the work tree. So when a file changed by got cherrypick gets committed with got commit, the log messages of the relevant merged commits appear in the editor — and you should tweak those messages to convey why you cherrypicked the changes. Then upon exiting the editor, if the time stamp of the log message file is unchanged or the log message is empty, got commit will fail with an unmodified or empty log message error. 😭

If all the changes in all files touched by a given commit are discarded, e.g. with got revert, that commit's log message record also disappears. Poof. 💀

got cherrypick will refuse to run if certain preconditions aren't met. If the work tree contains multiple base commits, you must first update it to a single base commit with got update. And if any relevant files already contain merge conflicts, those conflicts have to be resolved first. Sorry bestie, rules are rules. 🫶

The options for got cherrypick are as follows:

-l — Display a list of commit log messages recorded by cherrypick operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only show the log message of the specified commit.

If invoked in a work tree, only log messages recorded by cherrypick operations in the current work tree will be displayed. Otherwise, all commit log messages will be displayed irrespective of the work tree in which they were created. This option cannot be used with -X.

-X — Delete log messages created by previous cherrypick operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only delete the log message of the specified commit.

If invoked in a work tree, only log messages recorded by cherrypick operations in the current work tree will be deleted. Otherwise, all commit log messages will be deleted irrespective of the work tree in which they were created. This option cannot be used with -l.

🌸 `backout [-lX] [commit]` 🌸

(alias: bo)

Reverse-merge changes from a single commit into the work tree. The specified commit should be on the same branch as the work tree's base commit. It's giving undo, but make it fancy. 🙈

The expected argument is a commit ID, or a reference name or keyword that gets resolved into a commit ID. An abbreviated hash argument gets expanded to a full commit ID automatically, provided the abbreviation is unique. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. Keywords and references may be appended with :+ or :- modifiers and an optional integer N to denote the *N*th descendant or antecedent by first parent traversal, respectively — for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, wip:+5 will denote the 5th generation descendant of the commit resolved by the "wip" reference. A :+ or :- modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).

Show the status of each affected file, using the following status codes:

G      file was merged
C      file was merged and conflicts occurred during merge
!      changes destined for a missing file were not merged
D      file was deleted
d      file's deletion was prevented by local modifications
A      new file was added
~      changes destined for a non-regular file were not merged
?      changes destined for an unversioned file were not merged

The reverse-merged changes will appear as local changes in the work tree, which may be viewed with got diff, amended manually or with further got backout commands, committed with got commit. 🎀

If invoked in a work tree where no rebase, histedit, or merge operation is taking place, got backout creates a record of commits which have been reverse-merged into the work tree. When a file changed by got backout is committed with got commit, the log messages of relevant reverse-merged commits will then appear in the editor, where the messages should be further adjusted to convey the reasons for backing out the changes. Upon exiting the editor, if the time stamp of the log message file is unchanged or the log message is empty, got commit will fail with an unmodified or empty log message error. 😭

If all the changes in all files touched by a given commit are discarded, e.g. with got revert, this commit's log message record will also disappear. Gone. ✨

got backout will refuse to run if certain preconditions are not met. If the work tree contains multiple base commits, it must first be updated to a single base commit with got update. If any relevant files already contain merge conflicts, these conflicts must be resolved first. 🫶

The options for got backout are as follows:

-l — Display a list of commit log messages recorded by backout operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only show the log message of the specified commit.

If invoked in a work tree, only log messages recorded by backout operations in the current work tree will be displayed. Otherwise, all commit log messages will be displayed irrespective of the work tree in which they were created. This option cannot be used with -X.

-X — Delete log messages created by previous backout operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only delete the log message of the specified commit.

If invoked in a work tree, only log messages recorded by backout operations in the current work tree will be deleted. Otherwise, all commit log messages will be deleted irrespective of the work tree in which they were created. This option cannot be used with -l.

👑 `rebase [-aCclX] [branch]` 👑

(alias: rb)

Rebase commits on the specified branch onto the tip of the current branch of the work tree. The branch must share common ancestry with the work tree's current branch. Rebasing begins with the first descendant commit of the youngest common ancestor commit shared by the specified branch and the work tree's current branch, and stops once the tip commit of the specified branch has been rebased. It's giving glow-up for your commit history, fr fr. 🌈

When got rebase is used as intended, the specified branch represents a local commit history and may already contain changes that are not yet visible in any other repositories. The work tree's current branch, which must be set with got update -b before starting the rebase operation, represents a branch from a remote repository which shares a common history with the specified branch but has progressed, and perhaps diverged, due to commits added to the remote repository. 💜

Rebased commits get stacked up on a temporary branch, and like, the work tree stays switched to that temp branch for the whole rebase operation, the entire time, no interruptions. The commits living on this branch represent the same changes with the same log messages as their counterparts on the original branch — but with different commit IDs. Once the rebase has finished successfully, that temporary branch becomes the new version of the branch you specified, and the work tree automatically gets switched over to it. And if author info is available via the GOT_AUTHOR environment variable, got.conf(5), or Git's user.name and user.email configuration settings, that author info is what gets used to identify the “committer” of the rebased commits. 💅

Old commits in their pre-rebase state get automatically backed up in the refs/got/backup/rebase reference namespace. As long as those references aren't removed, the older versions of the rebased commits stay in the repository and you can peek at them with the got rebase -l command. But the moment those references get removed, objects that become unreachable via any reference are subject to removal by Git's garbage collector or gotadmin cleanup. So like, don't be reckless bestie. 💀

While rebasing commits, it shows you the status of each affected file, using these status codes:

G — file was merged
C — file was merged and conflicts occurred during merge
! — changes destined for a missing file were not merged
D — file was deleted
d — file's deletion was prevented by local modifications
A — new file was added
~ — changes destined for a non-regular file were not merged
? — changes destined for an unversioned file were not merged

If merge conflicts happen, the rebase operation gets interrupted and may be continued once you've resolved those conflicts. And if any files with destined changes turn out to be missing or unversioned, or if files couldn't be deleted due to differences in deleted content, the rebase operation will be interrupted — this is on purpose, to prevent potentially incomplete changes from being committed to the repository without user intervention. You're free to modify the work tree however you want, and the rebase operation can be continued once the changes present in the work tree are considered complete. Or, alternatively, you can abort the rebase operation, which will leave the branch unmodified and the work tree switched back to its original branch. Escape hatch unlocked. 🦋

And here's a fun one: if a merge conflict gets resolved in a way that renders the merged change into a no-op change, the corresponding commit will be elided when the rebase operation continues. Gone, poof, nothing. ✨

got rebase will straight-up refuse to run if certain preconditions aren't met, and honestly, valid:

If the branch is not in the refs/heads/ reference namespace, the branch may not be rebased.
If the work tree is not yet fully updated to the tip commit of its branch, then the work tree must first be updated with got update.
If changes have been staged with got stage, these changes must first be committed with got commit or unstaged with got unstage.
If the work tree contains local changes, these changes must first be committed with got commit or reverted with got revert.
If the branch contains changes to files outside of the work tree's path prefix, the work tree cannot be used to rebase this branch.

The got update, got integrate, got merge, got commit, and got histedit commands will all refuse to run while a rebase operation is in progress. Other commands which manipulate the work tree may be used for conflict resolution purposes though, so you're not fully locked out. 🫶

Oh and also — if the specified branch is already based on the work tree's current branch, then literally no commits need to be rebased, and got rebase will simply switch the work tree to the specified branch and update files in the work tree accordingly. Casual. 👑

The options for got rebase are as follows:

-a — Abort an interrupted rebase operation. If this option is used, no other command-line arguments are allowed.
-C — Allow a rebase operation to continue with files in conflicted status. This option should generally be avoided, and can only be used with the -c option.
-c — Continue an interrupted rebase operation. If this option is used, no other command-line arguments are allowed except -C.
-l — Show a list of past rebase operations, represented by references in the refs/got/backup/rebase reference namespace.

It displays the author, date, and log message of each backed up commit, the object ID of the corresponding post-rebase commit, and the object ID of their common ancestor commit. Given these object IDs, the got log command with the -c and -x options can be used to examine the history of either version of the branch, and the got branch command with the -c option can be used to create a new branch from a pre-rebase state if you want.

If a branch is specified, only show commits which at some point in time represented this branch. Otherwise, it lists all backed up commits for any branches.

If this option is used, got rebase does not require a work tree. None of the other options can be used together with -l.

-X — Delete backups created by past rebase operations, represented by references in the refs/got/backup/rebase reference namespace.

If a branch is specified, only delete backups which at some point in time represented this branch. Otherwise, delete all references found within refs/got/backup/rebase.

Any commit, tree, tag, and blob objects belonging to deleted backups remain in the repository and may be removed separately with Git's garbage collector or gotadmin cleanup.

If this option is used, got rebase does not require a work tree. None of the other options can be used together with -X.

🌸 `histedit [-aCcdeflmX] [-F histedit-script] [branch]` (alias: `he`) 🌸

Edit commit history between the work tree's current base commit and the tip commit of the work tree's current branch. Rewriting the past, main character energy fr fr. 📜

The got histedit command requires the GOT_AUTHOR environment variable to be set — unless an author has been configured in got.conf(5), or Git's user.name and user.email configuration settings can be obtained from the repository's .git/config file or from Git's global ~/.gitconfig configuration file.

Before starting a histedit operation, the work tree's current branch must be set with got update -b to the branch which should be edited — unless this branch is already the current branch of the work tree. The tip of this branch represents the upper bound (inclusive) of commits touched by the histedit operation.

Furthermore, the work tree's base commit must be set with got update -c to a point in this branch's commit history where editing should begin. This commit represents the lower bound (non-inclusive) of commits touched by the histedit operation.

Editing of commit history is controlled via a histedit script, which can be written in an editor based on a template, passed on the command line, or generated with the -d, -e, -f, or -m options. Quitting the editor without saving the file will abort the histedit operation. 💀

The format of the histedit script is line-based. Each line in the script begins with a command name, followed by whitespace and an argument. For most commands, the expected argument is a commit ID. Any remaining text on the line is ignored. Lines which begin with the # character are ignored entirely.

The available histedit script commands are as follows:

pick commit — Use the specified commit as it is.
edit commit — Apply the changes from the specified commit, but then interrupt the histedit operation for amending, without creating a commit. While the histedit operation is interrupted, arbitrary files may be edited, and commands which manipulate the work tree can be used freely. The got add and got remove commands can be used to add new files or remove existing ones. The got revert -p command can be used to eliminate arbitrary changes from files in the work tree. The got stage -p command may be used to prepare a subset of changes for inclusion in the next commit. Finally, the got commit command can be used to insert arbitrary commits into the edited history. Regular editing of history must eventually be resumed by running got histedit -c.
fold commit — Combine the specified commit with the next commit listed further below that will be used.
drop commit — Remove this commit from the edited history.
mesg commit — Open an editor to create a new log message for this commit.

Every commit in the history you're editing has to show up in the script, bestie. Like, all of them. No skipping. You can re-order the lines to shuffle the order the commits land in, but no commit may be listed more than once — that's the rule, don't test it. 🙅‍♀️

Edited commits get gathered up on a temporary branch, and your work tree just… stays switched to it for the whole entire histedit operation. Once history editing finishes successfully, that temp branch becomes the new version of your work tree's branch and the work tree auto-switches over. Seamless. Iconic. ✨

🎀 the backup situation (protect ya commits)

Old commits in their pre-histedit state get backed up automatically into the refs/got/backup/histedit reference namespace. As long as those references aren't removed, the older versions of your edited commits stay in the repository and you can peek at them with the got histedit -l command. 👀

Careful tho — once those references are removed, objects that become unreachable via any reference are subject to removal by Git's garbage collector or gotadmin cleanup. So like, don't delete the backup if you're not sure. 🙈

🔍 status codes while merging commits

While merges are happening, you get the status of each affected file, and the codes mean:

G — file was merged ✅
C — file was merged and conflicts occurred during merge 😭
! — changes destined for a missing file were not merged
D — file was deleted
d — file's deletion was prevented by local modifications
A — new file was added ✨
~ — changes destined for a non-regular file were not merged
? — changes destined for an unversioned file were not merged

💀 when things get messy

If merge conflicts happen, the histedit operation gets interrupted and you can continue it once the conflicts are resolved. And if any files with destined changes turn out to be missing or unversioned, or if files couldn't be deleted because the deleted content differs — the histedit operation gets interrupted, on purpose, to stop potentially incomplete changes from getting committed to the repository without you intervening. ngl that's actually very thoughtful of it.

The work tree may be modified however you want, and the histedit operation can be continued once the changes present in the work tree are considered complete. Alternatively, you can abort the whole thing, which leaves the work tree switched back to its original branch. No hard feelings. 🫶

Also, if a merge conflict gets resolved in a way that turns the merged change into a no-op change, the corresponding commit will be elided when the histedit operation continues. Poof. gone. 🦋

🚫 when `got histedit` flat-out refuses

got histedit will refuse to run if certain preconditions are not met. Let's go through them:

If the work tree's current branch is not in the refs/heads/ reference namespace, the history of that branch may not be edited. Periodt.
If the work tree contains multiple base commits, it must first be updated to a single base commit with got update.
If changes have been staged with got stage, those changes must first be committed with got commit or unstaged with got unstage.
If the work tree contains local changes, those changes must first be committed with got commit or reverted with got revert.
If the edited history contains changes to files outside of the work tree's path prefix, the work tree cannot be used to edit the history of this branch.

🔒 commands that get locked out mid-histedit

The got update, got rebase, got merge, and got integrate commands will refuse to run while a histedit operation is in progress. Sorry bestie, they're on timeout. ✋

Other commands which manipulate the work tree may still be used, and got commit may be used to commit arbitrary changes to the temporary branch while the histedit operation is interrupted. So you're not fully locked out, just... semi-locked out. 💅

The options for got histedit are as follows:

-a — Abort an interrupted histedit operation. If this option is used, no other command-line arguments are allowed.
-C — Allow a histedit operation to continue with files in conflicted status. This option should generally be avoided, and can only be used with the -c option.
-c — Continue an interrupted histedit operation. If this option is used, no other command-line arguments are allowed except -C.
-d — Drop all commits. This option is a quick equivalent to a histedit script which drops all commits. The -d option can only be used when starting a new histedit operation. If this option is used, no other command-line arguments are allowed.
-e — Interrupt the histedit operation for editing after merging each commit. This option is a quick equivalent to a histedit script which uses the edit command for all commits. The -e option can only be used when starting a new histedit operation. If this option is used, no other command-line arguments are allowed.
-F histedit-script — Use the specified histedit-script instead of opening a temporary file in an editor where a histedit script can be written.
-f — Fold all commits into a single commit. This option is a quick equivalent to a histedit script which folds all commits, combining them all into one commit. The -f option can only be used when starting a new histedit operation. If this option is used, no other command-line arguments are allowed.
-l — Show a list of past histedit operations, represented by references in the refs/got/backup/histedit reference namespace.

Display the author, date, and log message of each backed up commit, the object ID of the corresponding post-histedit commit, and the object ID of their common ancestor commit. Given these object IDs, the got log command with the -c and -x options can be used to examine the history of either version of the branch, and the got branch command with the -c option can be used to create a new branch from a pre-histedit state if desired.

If a branch is specified, only show commits which at some point in time represented this branch. Otherwise, list all backed up commits for any branches.

If this option is used, got histedit does not require a work tree. None of the other options can be used together with -l.

-m — Edit log messages only. This option is a quick equivalent to a histedit script which edits only log messages but otherwise leaves every picked commit as-is. The -m option can only be used when starting a new histedit operation. If this option is used, no other command-line arguments are allowed.
-X — Delete backups created by past histedit operations, represented by references in the refs/got/backup/histedit reference namespace.

If a branch is specified, only delete backups which at some point in time represented this branch. Otherwise, delete all references found within refs/got/backup/histedit.

Any commit, tree, tag, and blob objects belonging to deleted backups remain in the repository and may be removed separately with Git's garbage collector or gotadmin cleanup.

If this option is used, got histedit does not require a work tree. None of the other options can be used together with -X.

✨ integrate branch ✨

(alias: ig)

Integrate the specified branch into the work tree's current branch. Files in the work tree get updated to match the contents on the integrated branch, and the reference of the work tree's branch is changed to point at the head commit of the integrated branch. 💫

After integration, both branches can be considered equivalent — they're both pointing at the same commit. Both branches stay available for future work, if you want them. And in case the integrated branch is no longer needed, it may be deleted with got branch -d.

Show the status of each affected file, using the following status codes:

U — file was updated
D — file was deleted
A — new file was added
~ — versioned file is obstructed by a non-regular file
! — a missing versioned file was restored

got integrate will refuse to run if certain preconditions are not met. Most importantly: the branch must have been rebased onto the work tree's current branch with got rebase before it can be integrated, in order to linearize commit history and resolve merge conflicts. No shortcuts on that one, bestie. 🫠

Also:

If the work tree contains multiple base commits, it must first be updated to a single base commit with got update.
If changes have been staged with got stage, those changes must first be committed with got commit or unstaged with got unstage.
If the work tree contains local changes, those changes must first be committed with got commit or reverted with got revert.

🌈 merge [-aCcMn] [branch] 🌈

(alias: mg)

Merge the specified branch into the current branch of the work tree. Here's the tea 🍵:

If the branches have diverged, merge changes into the work tree and create a merge commit.
Otherwise, if the specified branch is already based on the work tree's current branch, make the work tree's current branch equivalent to the specified branch and update files in the work tree accordingly.

Merge commits are commits with multiple parents, bestie — and here's the tea: the tip commit of the work tree's current branch is the first parent, and the tip commit of the branch you named is the second parent. And your current branch has to live in the refs/heads/ reference namespace, which you can set up with got update -b before you even start merging. 🫶

No ancestral relationship needed between the two branches, okay? Zero. None. And if the two branches have already been merged before, only the new changes get merged. Iconic.

You literally cannot make merge commits with more than two parents. Not a thing. So if you've got three-plus branches to merge, you just do multiple merges, two parents each, one after another. It's giving assembly line. 💅

If you want that strictly linear project history vibe, got rebase should generally be your go-to over got merge. That said — even the most linear girlies sometimes need a merge commit, like when you're pulling in new versions of third-party code sitting on vendor branches that were made with got import. So keep it in your back pocket. ✨

While it's merging those changes from the branch into the work tree, it shows you the status of every affected file with these codes:

U — file was updated
G — file was merged
C — file was merged and conflicts occurred during merge
! — changes destined for a missing file were not merged
D — file was deleted
d — file's deletion was prevented by local modifications
A — new file was added
~ — changes destined for a non-regular file were not merged
? — changes destined for an unversioned file were not merged

If merge conflicts happen, the merge gets interrupted, and you have to resolve those conflicts before it can continue. No skipping. 😭

And if any files with destined changes turn out to be missing or unversioned, or if files couldn't be deleted because the deleted content differs, the merge gets interrupted too — this is to stop potentially incomplete changes from getting committed to the repo without you actually deciding to. From there you can mess with the work tree however you want, and continue the merge once the work tree's changes look complete to you. Or alternatively, abort the whole thing, which leaves the work tree's current branch unmodified. Your call, bestie. 🌸

got merge will refuse to run if certain preconditions aren't met. Periodt.

So let's run the vibe check:

If the work tree's current branch isn't in the refs/heads/ reference namespace, you must first switch it to a branch in the refs/heads/ namespace with got update -b.
If the work tree isn't fully updated to the tip commit of its branch, update it first with got update.
If the work tree has multiple base commits, update it to a single base commit first with got update.
If changes have been staged with got stage, commit them first with got commit or unstage them with got unstage.
If the work tree has local changes, commit them with got commit or revert them with got revert.
If the branch contains changes to files outside of the work tree's path prefix, then the work tree straight up cannot be used to merge that branch.

While a merge operation is in progress, the got update, got commit, got rebase, got histedit, got integrate, and got stage commands will refuse to run. Like, hard no. Other commands that manipulate the work tree may still be used for conflict resolution purposes though. 🧚

The options for got merge are as follows:

-a — Abort an interrupted merge operation. If you use this option, no other command-line arguments are allowed.
-C — Allow a merge operation to continue with files in conflicted status. This one should generally be avoided, and can only be used with the -c option.
-c — Continue an interrupted merge operation. If you use this option, no other command-line arguments are allowed except -C.
-M — Create a merge commit even if the branches have not diverged.
-n — Merge changes into the work tree as usual but do not create a merge commit immediately. You can adjust the merge result however you like before creating a merge commit with got merge -c. Or alternatively, abort the merge with got merge -a.

✨ `stage` ✨ (aka the glow-up station)

stage [-lpS] [-F response-script] [path ...]

(alias: sg)

Okay so stage takes your local changes and stages them for inclusion in the next commit. If you don't specify a path, it stages everything in the work tree. Otherwise it stages changes at or within the paths you gave it. Paths can be staged as long as they're added, modified, or deleted according to got status. 💖

It'll show you the status of each affected file with these codes:

A — file addition has been staged
M — file modification has been staged
D — file deletion has been staged

Staged file contents get saved into newly created blob objects in the repository, and those blobs get referred to by tree objects once the staged changes are committed. It's a whole pipeline, no cap. 🔥

Staged changes affect how got commit, got status, and got diff behave, so listen up:

While paths with staged changes exist, got commit will refuse to commit any paths that don't have staged changes.
Local changes made on top of staged changes can only be committed if the path is staged again, or if the staged changes are committed first.
got status shows both local changes and staged changes.
got diff can display local changes relative to staged changes, and staged changes relative to the repository.
got revert cannot revert staged changes, but it can be used to revert local changes created on top of staged changes.

The options for got stage are as follows:

-F response-script — With the -p option, read y, n, and q responses line-by-line from the specified response-script file instead of prompting interactively.
-l — Instead of staging new changes, list paths that are already staged, along with the IDs of staged blob objects and stage status codes. If you provided paths on the command line, show the staged paths among the specified paths. Otherwise, show all staged paths.
-p — Instead of staging an entire changed file, interactively select or reject changes for staging based on y (stage change), n (reject change), and q (quit staging this file) responses. If a file is in modified status, individual patches derived from the modified file content can be staged. Files in added or deleted status may only be staged or rejected in their entirety. 👑
-S — Allow staging of symbolic links that point outside of the path space under version control. By default got stage rejects such symbolic links due to safety concerns. As a precaution, got may decide to represent such a symbolic link as a regular file containing the link's target path, rather than creating an actual symbolic link pointing outside of the work tree. Use of this option is discouraged because external mechanisms such as make obj are better suited for managing symbolic links to paths not under version control.

got stage will refuse to run if certain preconditions aren't met.

If a file contains merge conflicts, those conflicts must be resolved first. And if a file is out of date relative to the head commit on the work tree's current branch, the file must be updated with got update before it can be staged — though ngl, that doesn't stop the file from going out-of-date at some point after you staged it. 🙈

The got update, got rebase, got merge, and got histedit commands will refuse to run while staged changes exist. And if staged changes can't be committed because a staged path is out of date, the path must be unstaged with got unstage before it can be updated with got update, and then it can be staged again if needed.

✨ `unstage` ✨

unstage [-p] [-F response-script] [path ...]

(alias: ug)

unstage merges staged changes back into the work tree and puts the affected paths back into non-staged status. If you don't specify a path, it unstages all staged changes across the entire work tree. Otherwise, it unstages changes at or within the paths you named. 🦋

It shows the status of each affected file with these codes:

G — file was unstaged
C — file was unstaged and conflicts occurred during merge
! — changes destined for a missing file were not merged
D — file was staged as deleted and still is deleted
d — file's deletion was prevented by local modifications
~ — changes destined for a non-regular file were not merged

The options for got unstage are as follows:

-F response-script — With the -p option, read y, n, and q responses line-by-line from the specified response-script file instead of prompting interactively.
-p — bestie, instead of yeeting the ENTIRE content of a changed file out of the staging area, this lets you hand-pick ✨ interactively ✨ which changes get unstaged and which stay. You answer with "y" (unstage change), "n" (keep change staged), or "q" (quit unstaging this file) and she does the thing 💅. If a file is staged in modified status, individual patches derived from the staged file content can be unstaged. Files staged in added or deleted status may only be unstaged in their entirety — that's just the rules, no cap.

`cat [-P] [-c commit] [-r repository-path] arg ...`</p>

Okay so this one's literally named after cats and it just parses and prints the contents of objects to standard output in a line-based text format 📜✨. Content of commit, tree, and tag objects is printed in a way similar to the actual content stored in such objects. Blob object contents are printed as they would appear in files on disk. it's giving "peek behind the curtain" energy fr fr.

She'll attempt to interpret each argument as a reference, a tag name, or an object ID. References will be resolved to an object ID. Tag names will resolved to a tag object. An abbreviated hash argument will be expanded to a full commit ID automatically, provided the abbreviation is unique 🫶.

And if none of the above interpretations produce a valid result, or if the -P option is used, she'll attempt to interpret the argument as a path which will be resolved to the ID of an object found at this path in the repository.

The options for got cat are as follows:

-c commit — look up paths in the specified commit. If this option is not used, paths are looked up in the commit resolved via the repository's HEAD reference.

The expected argument is a commit ID, or a reference name or keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full commit ID automatically, provided the abbreviation is unique 👑. The keywords :base and :head resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and references may be appended with :+ or :- modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively 🌳; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, quux:-8 will denote the 8th generation ancestor of the commit resolved by the quux reference. A :+ or :- modifier without a trailing integer has an implicit 1 appended (e.g., :base:+ is equivalent to :base:+1). like??? the lore goes DEEP 😭

-P — interpret all arguments as paths only 🛣️. This option can be used to resolve ambiguity in cases where paths look like tag names, reference names, or object IDs. when a file is named v1.0-release and you're out here fighting for your life 💀
-r repository-path — use the repository at the specified path. If not specified, assume the repository is located at or above the current working directory. If this directory is a got work tree, use the repository path associated with this work tree.

`info [path ...]`

Display meta-data stored in a work tree 🧚. See got-worktree(5) for details — she's holding the receipts.

The work tree to use is resolved implicitly by walking upwards from the current working directory. she just knows where she is, main character energy for real.

If one or more path arguments are specified, show additional per-file information for tracked files located at or within these paths. If a path argument corresponds to the work tree's root directory, display information for all tracked files. yes bestie, all of them, we're being thorough 🌈.

🚫 Ignore Patterns 🙈

got status and got add read patterns from .cvsignore and .gitignore files in each traversed directory and will not display or add unversioned files which match these patterns. The patterns are matched according to glob(7) rules, with extensions to improve compatibility with cvs(1) and git(1) ✨. Patterns from each .cvsignore or .gitignore file are matched relative to the directory containing that file.

So like, here's the cheat sheet:

If a pattern begins with two asterisks followed by a slash, **/, the remainder of the pattern will match at any directory at or below the directory containing .cvsignore or gitignore file. (yes, the original really does write it as gitignore there, no dot, we don't fix it, we respect it 💅)
Two asterisks surrounded by slashes, /**/, in the middle of a pattern will match one directory or more.
Patterns which end with a slash, /, will only match directories, and any paths below matching directories will be ignored.

⚠️ Now the drama. Unlike cvs(1), got only supports a single ignore pattern per line. Unlike git(1), got does not support negated ignore patterns prefixed with !, and does not match patterns at arbitrary depth relative to the .gitignore file unless they begin with **/. For better git(1) compatibility, patterns beginning with a slash are matched as if the slash were not present.

that's it, that's the whole vibe check 🫶

🌍 ENVIRONMENT 🌍

GOT_AUTHOR — the author's name and email address, such as "Flan Hacker ⟨flan_hacker@openbsd.org⟩" 💖. Used by the got commit, got import, got rebase, got merge, and got histedit commands. Because git(1) may fail to parse commits without an email address in author data, got attempts to reject GOT_AUTHOR environment variables with a missing email address — she's protecting you from yourself, periodt.

GOT_AUTHOR will be overridden by configuration settings in got.conf(5) or by Git's user.name and user.email configuration settings in the repository's .git/config file. The user.name and user.email configuration settings contained in Git's global ~/.gitconfig configuration file will only be used if neither got.conf(5) nor the GOT_AUTHOR environment variable provide author information. the hierarchy is hierarchy-ing 😌

GOT_IGNORE_GITCONFIG — if this variable is set then any remote repository definitions or author information found in Git configuration files will be ignored 🙅♀️.
GOT_LOG_DEFAULT_LIMIT — the default limit on the number of commits traversed by got log. If set to zero, the limit is unbounded 🌀. This variable will be silently ignored if it is set to a non-numeric value. (silently. she won't even argue with you. iconic.)
VISUAL, EDITOR — the editor spawned by got commit, got histedit, got import, or got tag ✍️. If not set, the vi(1) text editor will be spawned.

📁 FILES 📁

got.conf — repository-wide configuration settings for got. If present, a got.conf(5) configuration file located in the root directory of a Git repository supersedes any relevant settings in Git's config file 👑.
.got/got.conf — worktree-specific configuration settings for got. If present, a got.conf(5) configuration file in the .got meta-data directory of a work tree supersedes any relevant settings in the repository's got.conf(5) configuration file and Git's config file. the most specific one always wins, that's just how she moves 💅

🚪 EXIT STATUS 🚪

The got utility exits 0 on success, and >0 if an error occurs. that's it, binary queen 🌸

🌟 EXAMPLES 🌟

Enable tab-completion of got command names in ksh(1):

$ set -A complete_got_1 -- $(got -h 2>&1 | sed -n s/commands://p)

Clone an existing Git repository for use with got:

$ cd /var/git/
$ got clone ssh://git@github.com/openbsd/src.git

Unfortunately, many of the popular Git hosting sites do not offer anonymous access via SSH 😭. Such sites will require an account to be created, and a public SSH key to be uploaded to this account, before repository access via ssh:// URLs will work. bureaucracy, ugh.

Most sites offer anonymous repository access via HTTPS:

$ cd /var/git/
$ got clone https://github.com/openbsd/src.git

Alternatively, for quick and dirty local testing of got a new Git repository could be created and populated with files, e.g. from a temporary CVS checkout located at /tmp/src:

$ got init /var/git/src.git
$ got import -r /var/git/src.git -I CVS -I obj /tmp/src

Check out a work tree from the Git repository to /usr/src:

$ got checkout /var/git/src.git /usr/src

View local changes in a work tree directory:

$ got diff | less

In a work tree, display files in a potentially problematic state ⚠️:

$ got status -s 'C!~?'

Interactively revert selected local changes in a work tree directory:

$ got revert -p -R .

In a work tree or a git repository directory, list all branch references:

$ got branch -l

As above, but list the most recently modified branches only:

$ got branch -lt | head

In a work tree or a git repository directory, create a new branch called unified-buffer-cache which is forked off the master branch:

$ got branch -c master unified-buffer-cache

Switch an existing work tree to the branch unified-buffer-cache. Local changes in the work tree will be preserved and merged if necessary:

$ got update -b unified-buffer-cache

Create a new commit from local changes in a work tree directory. This new commit will become the head commit of the work tree's current branch:

$ got commit

In a work tree or a git repository directory, view changes committed in the 3 most recent commits to the work tree's branch, or the branch resolved via the repository's HEAD reference, respectively:

$ got log -p -l 3

As above, but display changes in the order in which patch(1) could apply them in sequence:

$ got log -p -l 3 -R

In a work tree or a git repository directory, log the history of a subdirectory:

$ got log sys/uvm

Okay so when you're chillin' inside a work tree, paths are relative to wherever you're currently standing (your current working directory) — so this command logs the sys/uvm subdirectory:

$ cd sys/uvm && got log .

And this command? Literally the same effect. Iconic behavior, honestly.

$ cd sys/dev/usb && got log ../../uvm

And this one shows you work tree meta-data about every single tracked file:

$ cd /usr/src
$ got info . | less

Adding new files and yeeting obsolete ones in a work tree directory:

$ got add sys/uvm/uvm_ubc.c
$ got remove sys/uvm/uvm_vnode.c

A file can be renamed or moved by removing it from its old location and adding it at the new one:

$ cp oldfile.c newfile.c
$ got remove oldfile.c
$ got add newfile.c

⚠️ heads up bestie: got does not yet follow file history across renames. But git(1) will be able to do so regardless. So git's got you either way ✨

Create a brand new commit from local changes in a work tree directory, with a pre-defined log message:

$ got commit -m 'unify the buffer cache'

Orrr, alternative route — create a new commit from local changes in a work tree directory, but with a log message that you prepared ahead of time in the file /tmp/msg:

$ got commit -F /tmp/msg

Update any work tree checked out from the “unified-buffer-cache” branch to the latest commit on this branch:

$ got update

Roll file content on the unified-buffer-cache branch back by one commit, and then fetch that rolled-back change into the work tree as a local change so you can amend it and maybe commit it again:

$ got backout unified-buffer-cache
$ got commit -m 'roll back previous'
$ # now back out the previous backout :-)
$ got backout unified-buffer-cache

Not the double backout 💀 but yes, that's literally what it says.

Fetch new changes on the remote repository's “master” branch, making them visible on the local repository's “origin/master” branch:

$ cd /usr/src
$ got fetch

Rebase the local “master” branch to merge the new changes that are now visible on the “origin/master” branch:

$ cd /usr/src
$ got update -b origin/master
$ got rebase master

Rebase the “unified-buffer-cache” branch on top of the new head commit of the “master” branch:

$ got update -b master
$ got rebase unified-buffer-cache

Create a patch from all changes on the unified-buffer-cache branch. The patch can be mailed out for review and applied to OpenBSD's CVS tree:

$ got diff master unified-buffer-cache > /tmp/ubc.diff

Edit the entire commit history of the “unified-buffer-cache” branch:

$ got update -b unified-buffer-cache
$ got update -c master
$ got histedit

Histedit said "entire commit history" and meant it fr fr.

Before working against existing branches in a repository cloned with git clone --bare instead of got clone, a Git “refspec” must be configured to map all references in the remote repository into the “refs/remotes” namespace of the local repository. You can achieve this by setting Git's remote.origin.fetch configuration variable to the value “+refs/heads/*:refs/remotes/origin/*” with the git config command:

$ cd /var/git/repo
$ git config remote.origin.fetch
'+refs/heads/*:refs/remotes/origin/*'

Additionally, the “mirror” option must be disabled:

$ cd /var/git/repo
$ git config remote.origin.mirror false

Alternatively, you can add the following git-fetch(1) configuration item manually to the Git repository's config file:

[remote "origin"]
url = ...
fetch = +refs/heads/*:refs/remotes/origin/*
mirror = false

This configuration leaves the local repository's “refs/heads” namespace free for use by local branches checked out with got checkout and, if needed, created with got branch. Branches in the “refs/remotes/origin” namespace can now be updated with incoming changes from the remote repository with got fetch or git-fetch(1) without extra command line arguments — which is the whole vibe honestly. Newly fetched changes can be examined with got log.

Display changes on the remote repository's version of the “master” branch, as of the last time got fetch was run:

$ got log -c origin/master | less

As shown here, most commands accept abbreviated reference names such as “origin/master” instead of “refs/remotes/origin/master”. The latter is only needed in case of ambiguity. (iykyk — shorten when you can, be precise when you must.)

got rebase can be used to merge changes which are visible on the “origin/master” branch into the “master” branch. This will also merge local changes, if any, with the incoming changes:

$ got update -b origin/master
$ got rebase master

In order to make changes committed to the “unified-buffer-cache” visible on the “master” branch, the “unified-buffer-cache” branch can be rebased onto the “master” branch:

$ got update -b master
$ got rebase unified-buffer-cache

Changes on the “unified-buffer-cache” branch can now be made visible on the “master” branch with got integrate. Because the rebase operation switched the work tree to the “unified-buffer-cache” branch, the work tree must be switched back to the “master” branch first:

$ got update -b master
$ got integrate unified-buffer-cache

Don't skip that first line!! The work tree is sitting on the wrong branch after the rebase, and got integrate needs you back on “master” first. Order matters bestie 💅

On the “master” branch, log messages for local changes can now be amended with “OK” by other developers and any other important new information:

$ got update -c origin/master
$ got histedit -m

If the remote repository offers write access, local changes on the “master” branch can be sent to the remote repository with got send. Usually, got send can be run without further arguments. The arguments shown here match defaults, provided the work tree's current branch is the “master” branch:

$ got send -b master origin

If the remote repository requires the HTTPS protocol, the git-push(1) command must be used instead:

$ cd /var/git/src.git
$ git push origin master

When making contributions to projects which use the “pull request” workflow, SSH protocol repository access needs to be set up first. Once an account has been created on a Git hosting site it should be possible to upload a public SSH key for repository access authentication.

The “pull request” workflow will usually involve two remote repositories. In the real-life example below, the “origin” repository was forked from the “upstream” repository by using the Git hosting site's web interface. The got.conf(5) file in the local repository describes both remote repositories:

# Jelmers's repository, which accepts pull requests
remote "upstream" {
    server git@github.com
    protocol ssh
    repository "/jelmer/dulwich"
    branch { "master" }
}

# Stefan's fork, used as the default remote repository
remote "origin" {
    server git@github.com
    protocol ssh
    repository "/stspdotname/dulwich"
    branch { "master" }
}

With this configuration, Stefan can create commits on “refs/heads/master” and send them to the “origin” repository by running:

$ got send -b master origin

The changes can now be proposed to Jelmer by opening a pull request via the Git hosting site's web interface. If Jelmer requests further changes to be made, additional commits can be created on the “master” branch and be added to the pull request by running got send again.

If Jelmer prefers additional commits to be “squashed” then the following commands can be used to achieve this:

$ got update -b master
$ got update -c origin/master
$ got histedit -f
$ got send -f -b master origin

In addition to reviewing the pull request in the web user interface, Jelmer can fetch the pull request's branch into his local repository and create a local branch which contains the proposed changes:

$ got fetch -R refs/pull/1046/head origin
$ got branch -c refs/remotes/origin/pull/1046/head pr1046

Once Jelmer has accepted the pull request, Stefan can fetch the merged changes, and possibly several other new changes, by running:

$ got fetch upstream

The merged changes will now be visible under the reference “refs/remotes/upstream/master”. The local “master” branch can now be rebased on top of the latest changes from upstream:

$ got update -b upstream/master
$ got rebase master

As an alternative to got rebase, branches can be merged with got merge:

$ got update -b master
$ got merge upstream/master

The question of whether to rebase or merge branches is philosophical. When in doubt, refer to the software project's policies set by project maintainers. fr fr, this one's a culture question not a syntax question 🙈

As a final step, the forked repository's copy of the master branch needs to be kept in sync by sending the new changes there:

$ got send -f -b master origin

If multiple pull requests need to be managed in parallel, a separate branch must be created for each pull request with got branch. Each such branch can then be used as above, in place of “refs/heads/master”. Changes for any accepted pull requests will still appear under “refs/remotes/upstream/master,” regardless of which branch was used in the forked repository to create a pull request.

✨ SEE ALSO ✨

Go read these next, bestie, they're all part of the lore:

👑 AUTHORS 👑

okay so basically a whole squad of absolute legends built this thing, and they all deserve their flowers 💐 so here's the roll call, no cap:

Anthony J. Bentley <bentley@openbsd.org>
Christian Weisgerber <naddy@openbsd.org>
Florian Obser <florian@narrans.de>
Hiltjo Posthuma <hiltjo@codemadness.org>
James Cook <falsifian@falsifian.org>
Jasper Lievisse Adriaanse <j@jasper.la>
Josh Rickmar <jrick@zettaport.com>
Joshua Stein <jcs@openbsd.org>
Josiah Frentsos <jfrent@tilde.team>
Klemens Nanni <kn@openbsd.org>
Kyle Ackerman <kackerman0102@gmail.com>
Lorenz (xha) <me@xha.li>
Lucas Gabriel Vuotto <lucas@sexy.is>
Mark Jamsek <mark@jamsek.dev>
Martin Pieuchot <mpi@openbsd.org>
Mikhail Pchelin <misha@freebsd.org>
Neels Hofmeyr <neels@hofmeyr.de>
Omar Polo <op@openbsd.org>
Ori Bernstein <ori@openbsd.org>
Sebastien Marie <semarie@openbsd.org>
Stefan Sperling <stsp@openbsd.org>
Steven McDonald <steven@steven-mcdonald.id.au>
Ted Unangst <tedu@tedunangst.com>
Theo Buehler <tb@openbsd.org>
Thomas Adam <thomas@xteddy.org>
Tobias Heider <me@tobhe.de>
Todd C. Miller <Todd.Miller@sudo.ws>
Tom Jones <thj@freebsd.org>
Tracey Emery <tracey@traceyemery.net>
Yang Zhong <yzhong@freebsdfoundation.org>

and it's not just them btw, because parts of got, tog(1), gotd(8), and gotwebd(8) were derived from code that's under copyright by these icons:

Bjoern Hoehrmann
Caldera International
Daniel Hartmeier
David Gwynne
Esben Norby
Henning Brauer
Håkan Olsson
Ingo Schwarze
Jean-Francois Brousseau
Jerome Kasper
Joris Vink
Jyri J. Virkki
Larry Wall
Markus Friedl
Mike Larkin
Niall O'Higgins
Niklas Hallqvist
Ray Lai
Reyk Floeter
Ryan McBride
Theo de Raadt
Xavier Santolaria

and one last lil credit moment: got contains code contributed to the public domain by Austin Appleby. 🫶

💀 CAVEATS 💀

okay bestie, real talk time 🙈 — got is a work-in-progress and some features remain to be implemented. she's still growing, she's still blossoming 🦋

At present, the user has to fall back on git(1) to perform some tasks. In particular:

Writing to remote repositories over HTTP or HTTPS protocols requires git-push(1).
The creation of merge commits with more than two parent commits requires git-merge(1).
In situations where files or directories were moved around got will not automatically merge changes to new locations and git(1) will usually produce better results.

so yeah, sometimes you gotta call in git(1) as your backup dancer. it's not a flop, it's a collab 💅

and that's a wrap on the whole page, fr fr 🌸 this lil masterpiece lives in the Debian packaging, tagged with $Mdocdate$ as its date, filed under GOT(1) — so shoutout to Debian for carrying her, and shoutout to that date placeholder for forever keeping it cute and mysterious ✨ go forth and version-control responsibly, mwah 💖🎀

📦 where this page comes from

alpine 3.24: got-doc 0.126-r0 · ISC
ubuntu stonking: got 0.126-1build1 · ISC
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-02: a language model's rewrite of the original, under its terms

GOT(1)

🎀 NAME 🎀

🌸 SYNOPSIS 🌸

💅 DESCRIPTION 💅

🌱 init

📥 import

🧬 clone

✨ fetch ✨ (alias: fe)

✨ checkout ✨ (alias: co)

🌈 update

💜 status

⭐ log

🦋 got diff 🦋

👑 got blame 👑

🌳 tree — aka tr 🌳

🎀 ref 🎀

🦋 branch — aka br 🦋

✨ the options for got branch, bestie ✨

🏷️ tag

the options for got tag 💖

➕ add

the options for got add 🌸

🗑️ got remove (aka rm) — time to say bye bestie 💅

🩹 got patch (aka pa) — glow-up via diff 🌈

↩️ got revert (aka rv) — the undo button, no takebacks

📝 got commit (aka ci) — the main character moment 🎬