Ubuntu Manpage: got — Game of Trees

NAME

     got — Game of Trees

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. This 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.

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).

got 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 commands for got are as follows:

import [-b branch] [-I pattern] [-m message] [-r repository-path] directory
(alias: im)
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.

-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 [-almqv] [-b branch] [-R reference] repository-URL [directory]
(alias: cl)
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.

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.

git+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

ssh Short alias for git+ssh.

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.

-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 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
In addition to the branches and tags that will be fetched, fetch an
arbitrary reference from the remote repository's “refs/” namespace. This
option may be specified multiple times to build a list of additional
references to fetch. The specified reference may either be a path to a
specific reference, or a reference namespace which will cause all
references in this namespace to be fetched.

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

got clone will refuse to fetch references from the remote repository's
“refs/remotes/” or “refs/got/” namespace.

-v Verbose mode. Causes got clone to print debugging messages to standard
error output. This option will be passed to ssh(1) if applicable.
Multiple -v options increase the verbosity. The maximum is 3.

fetch [-adlqtvX] [-b branch] [-R reference] [-r repository-path] [remote-repository]
(alias: fe)
Fetch new changes from a remote repository. If no remote-repository is specified,
“origin” will be used. The remote repository's URL is obtained from the
corresponding entry in got.conf(5) or Git's config file of the local repository,
as created by got clone.

By default, any branches configured in got.conf(5) for the remote-repository will
be fetched. If got fetch is invoked in a work tree then this work tree's current
branch will be fetched, too, provided it is present on the server. If no branches
to fetch can be found in got.conf(5) or via a work tree, or said branches are not
found on the server, a branch resolved via the remote repository's HEAD reference
will be fetched. Likewise, if a HEAD reference for the remote-repository exists
but its target no longer matches the remote HEAD, then the new target branch will
be fetched. This default behaviour can be overridden with the -a and -b options.

New changes will be stored in a separate pack file downloaded from the server.
Optionally, separate pack files stored in the repository can be combined with
git-repack(1).

By default, branch references in the “refs/remotes/” reference namespace will be
updated to point at the newly fetched commits. The got rebase command can then be
used to make new changes visible on branches in the “refs/heads/” namespace,
merging incoming changes with the changes on those branches as necessary.

If the repository was created as a mirror with got clone -m, then all branches in
the “refs/heads/” namespace will be updated directly to match the corresponding
branches in the remote repository. If those branches contained local commits,
these commits will no longer be reachable via a reference and will therefore be at
risk of being discarded by Git's garbage collector or gotadmin cleanup.
Maintaining custom changes in a mirror repository is therefore discouraged.

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

The options for got fetch are as follows:

-a Fetch all branches from the remote repository's “refs/heads/” reference
namespace. This option can be enabled by default for specific
repositories in got.conf(5). Cannot be used together with the -b option.

-d Delete branches and tags from the local repository which are no longer
present in the remote repository. Only references are deleted. 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.

-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.

-q Suppress progress reporting output. The same option will be passed to
ssh(1) if applicable.

Each reference will be 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 will be 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.

got fetch will refuse to fetch references from the remote repository's
“refs/remotes/” or “refs/got/” namespace.

-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 Allow existing references in the “refs/tags” namespace to be updated if
they have changed on the server. If not specified, only new tag
references will be created.

-v Verbose mode. Causes got fetch 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.

-X Delete all references which correspond to a particular remote-repository
instead of fetching new changes. This can be useful when a remote
repository is being removed from got.conf(5).

With -X, the remote-repository argument is mandatory and no other options
except -r, -v, and -q are allowed.

Only references are 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 git-repack(1) and Git's garbage
collector.

checkout [-] [-b branch] [-c commit] [-p path-prefix] repository-path [work-tree-path]
(alias: co)
Copy files from a repository into a new work tree. Show the status of each
affected file, using the following status codes:

A new file was added
E file already exists in work tree's meta-data

If the work tree path is not specified, either use the last component of
repository path, or if a path prefix was specified use the last component of path
prefix.

The options for got checkout are as follows:

-b branch
Check out files from a commit on the specified branch. If this option is
not specified, a branch resolved via the repository's HEAD reference will
be used.

-c commit
Check out files from the specified commit on the selected branch. The
expected argument is a commit ID SHA1 hash or an existing reference or tag
name which will be resolved to a commit ID. An abbreviated hash argument
will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique. If this option is not specified, the most recent
commit on the selected branch will be used.

If the specified commit is not contained in the selected branch, a
different branch which contains this commit must be specified with the -b
option. If no such branch is known, a new branch must be created for this
commit with got branch before got checkout can be used. Checking out work
trees with an unknown branch is intentionally not supported.

-E Proceed with the checkout operation even if the directory at
work-tree-path is not empty. Existing files will be 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 will be checked out.

-q Silence progress output.

update [-q] [-b branch] [-c commit] [path ...]
(alias: up)
Update an existing work tree to a different commit. Change existing files in the
work tree as necessary to match file contents of this commit. Preserve any local
changes in the work tree and merge them with the incoming changes.

Files which already contain merge conflicts will not be updated to avoid further
complications. Such files will be updated when got update is run again after
merge conflicts have been resolved. If the conflicting changes are no longer
needed, affected files can be reverted with got revert before running got update
again.

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
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
specified paths will remain unchanged and will retain their previously recorded
base commit. Some got commands may 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.

got update cannot update paths with staged changes. If changes have been staged
with got stage, these changes must first be committed with got commit or unstaged
with got unstage.

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 in order to obtain 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. The expected argument is a
commit ID SHA1 hash or an existing reference or tag name which will be
resolved to a commit ID. An abbreviated hash argument will be expanded to
a full SHA1 hash automatically, provided the abbreviation is unique. If
this option is not specified, the most recent commit on the work tree's
branch will be used.

-q Silence progress output.

status [-I] [-S status-codes] [-s status-codes] [path ...]
(alias: st)
Show the current modification status of files in a work tree, using the following
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 the following 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

The options for got status are as follows:

-I Show unversioned files even if they match an ignore pattern.

-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.

For compatibility with cvs(1) and git(1), got status reads glob(7) patterns from
.cvsignore and .gitignore files in each traversed directory and will not display
unversioned files which match these patterns. Ignore patterns which end with a
slash, “/”, will only match directories. As an extension to glob(7) matching
rules, got status supports consecutive asterisks, “**”, which will match an
arbitrary amount of directories. Unlike cvs(1), got status only supports a single
ignore pattern per line. Unlike git(1), got status does not support negated
ignore patterns prefixed with “!”, and gives no special significance to the
location of path component separators, “/”, in a pattern.

log [-bdPpRs] [-C number] [-c commit] [-l N] [-r repository-path] [-S search-pattern] [-x
commit] [path]
Display 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
Set the number of context lines shown in diffs with -p. By default, 3
lines of context are shown.

-c commit
Start traversing history at the specified commit. The expected argument
is a commit ID SHA1 hash or an existing reference or tag name which will
be resolved to a commit ID. An abbreviated hash argument will be expanded
to a full SHA1 hash automatically, provided the abbreviation is unique.
If this option is not specified, default to the work tree's current branch
if invoked in a work tree, or to the repository's HEAD reference.

-d Display diffstat of changes introduced in each commit. Cannot be used
with the -s option.

-l N Limit history traversal to a given number of commits. If this option is
not specified, a default limit value of zero is used, which is treated as
an unbounded limit. The GOT_LOG_DEFAULT_LIMIT environment variable may be
set to change this default value.

-P Display the list of file paths changed in each commit, using the following
status codes:

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.

-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.

-R Determine a set of commits to display as usual, but display these commits
in reverse order.

-S search-pattern
If specified, show only commits with a log message, author name, committer
name, or ID SHA1 hash 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. Regular expression syntax is documented in re_format(7).

-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.

-x commit
Stop traversing commit history immediately after the specified commit has
been traversed. This option has no effect if the specified commit is
never traversed.

diff [-adPsw] [-C number] [-c commit] [-r repository-path] [object1 object2 | path ...]
(alias: di)
When invoked within a work tree without any arguments, display all local changes
in the work tree. If one or more path arguments are specified, only show changes
within the specified paths.

If two arguments are provided, treat each argument as a reference, a tag name, or
an object ID SHA1 hash, and display differences between the corresponding objects.
Both objects must be of the same type (blobs, trees, or commits). An abbreviated
hash argument will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique. If none of these interpretations produce a valid result
or if the -P option is used, and if got diff is running in a work tree, attempt to
interpret the two arguments as paths.

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.

The expected argument is a commit ID SHA1 hash or an existing reference or
tag name which will be resolved to a commit ID. An abbreviated hash
argument will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique.

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.

Cannot be used together with the -P option.

-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.

-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.

blame [-c commit] [-r repository-path] path
(alias: bl)
Display line-by-line history of a file at the specified path.

The options for got blame are as follows:

tree [-iR] [-c commit] [-r repository-path] [path]
(alias: tr)
Display a listing of files and directories at the specified directory path in the
repository. Entries shown in this listing may carry one of the following trailing
annotations:

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

Symbolic link entries are also annotated with the target path of the link.

If no path is specified, list the repository path corresponding to the current
directory of the work tree, or the root directory of the repository if there is no
work tree.

The options for got tree are as follows:

-c commit
List files and directories as they appear in the specified commit. The
expected argument is a commit ID SHA1 hash or an existing reference or tag
name which will be resolved to a commit ID. An abbreviated hash argument
will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique.

-i Show object IDs of files (blob objects) and directories (tree objects).

-R Recurse into sub-directories in the repository.

ref [-dlt] [-c object] [-r repository-path] [-s reference] [name]
Manage references in a repository.

References may be listed, created, deleted, and changed. When creating, deleting,
or changing a reference the specified name must be an absolute reference name,
i.e. it must begin with “refs/”.

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. The expected
object argument is a ID SHA1 hash or an existing reference or tag name
which will be resolved to the ID of a corresponding commit, tree, tag, or
blob object. Cannot be used together with any other options except -r.

-d Delete the reference with the specified name from the repository. 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. 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. Cannot be used together with any other options
except -r and -t.

-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.
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.

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.

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.

If invoked in a work tree without any arguments, print the name of the work tree's
current branch.

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 are as follows:

-c commit
Make a newly created branch reference point at the specified commit. The
expected commit argument is a commit ID SHA1 hash or an existing reference
or tag name which will be resolved to a commit ID.

-d name
Delete the branch with the specified name from the “refs/heads” or
“refs/remotes” reference namespace.

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

-l List all existing branches in the repository, including copies of remote
repositories' branches in the “refs/remotes/” reference namespace.

If invoked in a work tree, the work tree's current branch is shown with
one the following annotations:

* work tree's base commit matches the branch tip
~ work tree's base commit is out-of-date

-n Do not switch and update the work tree after creating a new branch.

-t Sort listed branches by modification time (most recently modified first)
instead of sorting by lexicographical order. Branches in the
“refs/heads/” reference namespace are listed before branches in
“refs/remotes/” regardless. Use of this option requires the -l option to
be used as well.

tag [-lVv] [-c commit] [-m message] [-r repository-path] [-s signer-id] name
Manage tags in a repository.

Tags are managed via references which live in the “refs/tags/” reference
namespace. The got tag command operates on references in this namespace only.
References in this namespace point at tag objects which contain a pointer to
another object, a tag message, as well as author and timestamp information.

Attempt to create a tag with the given name, and make this tag point at the given
commit. If no commit is specified, default to the latest commit on the work
tree's current branch if invoked in a work tree, and to a commit resolved via the
repository's HEAD reference otherwise.

The options for got tag are as follows:

-c commit
Make the newly created tag reference point at the specified commit. The
expected commit argument is a commit ID SHA1 hash or an existing reference
or tag name which will be resolved to a commit ID. An abbreviated hash
argument will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique.

-l List all existing tags in the repository instead of creating a new tag.
If a name argument is passed, show only the tag with the given name.

-m message
Use the specified tag message when creating the new tag. Without the -m
option, got tag opens a temporary file in an editor where a tag message
can be written.

-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 will sign the tag object by invoking
ssh-keygen(1) with the -Y sign command, using the signature namespace
“git” for compatibility with git(1).

-V Verify tag object signatures. If a name is specified, show and verify the
tag object with the provided name. Otherwise, list all tag objects and
verify 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
will be 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 [-IR] path ...
Schedule unversioned files in a work tree for addition to the repository in the
next commit. By default, files which match a got status ignore pattern will not
be added.

The options for got add are as follows:

-I Add files even if they match a got status ignore pattern.

-R Permit recursion into directories. If this option is not specified, got
add will refuse to run if a specified path is a directory.

remove [-fkR] [-s status-codes] path ...
(alias: rm)
Remove versioned files from a work tree and schedule them for deletion from the
repository in the next commit.

The options for got remove are as follows:

-f Perform the operation even if a file contains local modifications, and do
not raise an error if a specified path does not exist on disk.

-k Keep affected files on disk.

-R Permit recursion into directories. If this option is not specified, got
remove will refuse to run if a specified path is a directory.

-s status-codes
Only delete files with a modification status matching one of the single-
character status codes contained in the status-codes argument. The
following status codes may be specified:

M modified file (this implies the -f option)
! versioned file expected on disk but missing

patch [-nR] [-c commit] [-p strip-count] [patchfile]
(alias: pa)
Apply changes from patchfile to files in a work tree. Files added or removed by a
patch will be scheduled for addition or removal in the work tree.

The patch must be in the unified diff format as produced by got diff, git-diff(1),
or by diff(1) and cvs(1) diff when invoked with their -u options. If no patchfile
argument is provided, read unified diff data from standard input instead.

If the patchfile contains multiple patches, then attempt to apply each of them in
sequence.

Show the status of each affected file, using the following status 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 does not match at its exact line number, attempt to apply it somewhere
else in the file if a good spot can be found. Otherwise, the patch will fail to
apply.

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 this point will be left behind. Such changes can be viewed with
got diff and can be reverted with got revert if needed.

The options for got patch are as follows:

-c commit
Attempt to locate files within the specified commit for use as a merge-
base for 3-way merges. Ideally, the specified commit should contain
versions of files which the changes contained in the patchfile were based
on. Files will be located by path, relative to the repository root. If
the -p option is used then leading path components will be stripped before
paths are looked up in the repository.

If the -c option is not used then got patch will attempt to locate merge-
bases via object IDs found in patchfile meta-data, such as produced by got
diff or git-diff(1). Use of the -c option is only recommended in the
absence of such meta-data.

In case no merge-base is available for a file, changes will be applied
without doing a 3-way merge. Changes which do not apply cleanly may then
be rejected entirely, rather than producing merge conflicts in the patched
target file.

-n Do not make any modifications to the work tree. This can be used to check
whether a patch would apply without issues. If the patchfile contains
diffs that affect the same file multiple times, the results displayed may
be incorrect.

-p strip-count
Specify the number of leading path components to strip from paths parsed
from patchfile. If the -p option is not used, ‘a/’ and ‘b/’ path prefixes
generated by git-diff(1) will be recognized and stripped automatically.

-R Reverse the patch before applying it.

revert [-pR] [-F response-script] path ...
(alias: rv)
Revert any local changes in files at the specified paths in a work tree. File
contents will be overwritten with those contained in the work tree's base commit.
There is no way to bring discarded changes back after got revert!

If a file was added with got add, it will become an unversioned file again. If a
file was deleted with got remove, it will be 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 interactively.

-p Instead of reverting all changes in files, interactively select 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.

-R Permit recursion into directories. If this option is not specified, got
revert will refuse to run if a specified path is a directory.

commit [-CNnS] [-A author] [-F path] [-m message] [path ...]
(alias: ci)
Create a new commit in the repository from changes in a work tree and use this
commit as the new base commit for the work tree. If no path is specified, commit
all changes in the work tree. Otherwise, commit changes at or within the
specified paths.

If changes have been explicitly staged for commit with got stage, only commit
staged changes and reject any specified paths which have not been staged.

got commit opens a temporary file in an editor where a log message can be written
unless the -m option is used or the -F and -N options are used together.

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

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

Files which are not part of the new commit will retain their previously recorded
base commit. Some got commands may 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.

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.

The options for got commit are as follows:

-A author
Set author information in the newly created commit to author. This is
useful when committing changes on behalf of someone else. The author
argument must use the same format as the GOT_AUTHOR environment variable.

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.

Committing files with conflict markers should generally be avoided. Cases
where conflict markers must be stored in the repository for some
legitimate reason should be very rare. There are usually ways to avoid
storing conflict markers verbatim by applying appropriate programming
tricks.

-F path
Use the prepared log message stored in the file found at path when
creating the new commit. got commit opens a temporary file in an editor
where the prepared log message can be reviewed and edited further if
needed. Cannot be used together with the -m option.

-m message
Use the specified log message when creating the new commit. Cannot be
used together with the -F option.

-N This option prevents got commit from opening the commit message in an
editor. It has no effect unless it is used together with the -F option
and is intended for non-interactive use such as scripting.

-n This option prevents got commit from generating a diff of the to-be-
committed changes in a temporary file which can be viewed while editing a
commit message.

-S Allow the addition of symbolic links which point outside of the path space
that is under version control. By default, got commit will reject such
symbolic links due to safety concerns. As a precaution, got may decide to
represent such a symbolic link as a regular file which contains 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. 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 [-afqTv] [-b branch] [-d branch] [-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 is obtained 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 will be written to a temporary pack file
which 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 are 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. The -a option 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, default 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. This option 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 and got rebase 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 the -f option, new changes should be fetched with got
fetch and local branches should be rebased with got rebase, 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.

-q Suppress progress reporting output. The same option will be passed to
ssh(1) if applicable.

-T Attempt to send all tags from the local repository's “refs/tags/”
reference namespace. The -T option 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. The -t option
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 [-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 reference or a commit ID SHA1 hash. An abbreviated hash argument
will be expanded to a full SHA1 hash automatically, provided the abbreviation is
unique.

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 merged changes will appear as local changes in the work tree, which may be
viewed with got diff, amended manually or with further got cherrypick commands,
committed with got commit.

If invoked in a work tree where no rebase, histedit, or merge operation is taking
place, got cherrypick creates a record of commits which have been merged into the
work tree. When a file changed by got cherrypick is committed with got commit,
the log messages of relevant merged commits will then appear in the editor, where
the messages should be further adjusted to convey the reasons for cherrypicking
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.

got cherrypick 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 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. The expected
argument is a reference or a commit ID SHA1 hash. An abbreviated hash argument
will be expanded to a full SHA1 hash automatically, provided the abbreviation is
unique.

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

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.

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.

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 are accumulated on a temporary branch which the work tree will
remain switched to throughout the entire rebase operation. Commits 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 rebasing has completed
successfully, the temporary branch becomes the new version of the specified branch
and the work tree is automatically switched to it. If author information is
available via the GOT_AUTHOR environment variable, got.conf(5) or Git's user.name
and user.email configuration settings, this author information will be used to
identify the “committer” of rebased commits.

Old commits in their pre-rebase state are automatically backed up in the
“refs/got/backup/rebase” reference namespace. As long as these references are not
removed older versions of rebased commits will remain in the repository and can be
viewed with the got rebase -l command. Removal of these references makes objects
which become unreachable via any reference subject to removal by Git's garbage
collector or gotadmin cleanup.

While rebasing commits, show the status of each affected file, using the following
status codes:

If merge conflicts occur, the rebase operation is interrupted and may be continued
once conflicts have been resolved. If any files with destined changes are found
to be missing or unversioned, or if files could not be deleted due to differences
in deleted content, the rebase operation will be interrupted to prevent
potentially incomplete changes from being committed to the repository without user
intervention. The work tree may be modified as desired and the rebase operation
can be continued once the changes present in the work tree are considered
complete. Alternatively, the rebase operation may be aborted which will leave
branch unmodified and the work tree switched back to its original branch.

If a merge conflict is resolved in a way which renders the merged change into a
no-op change, the corresponding commit will be elided when the rebase operation
continues.

got rebase will refuse to run if certain preconditions are not met. 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 refuse to run while a rebase operation is in progress. Other commands which
manipulate the work tree may be used for conflict resolution purposes.

If the specified branch is already based on the work tree's current branch, then
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.

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.

-l Show a list of past rebase operations, represented by references in the
“refs/got/backup/rebase” reference namespace.

Display 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 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 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.

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.

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 SHA1 hash. 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 [log-message] Create a new log message for the commit of a preceding pick
or edit command on the previous line of the histedit script.
The optional log-message argument provides a new single-line
log message to use. If the log-message argument is omitted,
open an editor where a new log message can be written.

Every commit in the history being edited must be mentioned in the script. Lines
may be re-ordered to change the order of commits in the edited history. No commit
may be listed more than once.

Edited commits are accumulated on a temporary branch which the work tree will
remain switched to throughout the entire histedit operation. Once history editing
has completed successfully, the temporary branch becomes the new version of the
work tree's branch and the work tree is automatically switched to it.

Old commits in their pre-histedit state are automatically backed up in the
“refs/got/backup/histedit” reference namespace. As long as these references are
not removed older versions of edited commits will remain in the repository and can
be viewed with the got histedit -l command. Removal of these references makes
objects which become unreachable via any reference subject to removal by Git's
garbage collector or gotadmin cleanup.

While merging commits, show the status of each affected file, using the following
status codes:

If merge conflicts occur, the histedit operation is interrupted and may be
continued once conflicts have been resolved. If any files with destined changes
are found to be missing or unversioned, or if files could not be deleted due to
differences in deleted content, the histedit operation will be interrupted to
prevent potentially incomplete changes from being committed to the repository
without user intervention. The work tree may be modified as desired and the
histedit operation can be continued once the changes present in the work tree are
considered complete. Alternatively, the histedit operation may be aborted which
will leave the work tree switched back to its original branch.

If a merge conflict is resolved in a way which renders the merged change into a
no-op change, the corresponding commit will be elided when the histedit operation
continues.

got histedit 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, the history
of the branch may not be edited. 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, 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 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.

The got update, got rebase, got merge, and got integrate commands will refuse to
run while a histedit operation is in progress. Other commands which manipulate
the work tree may be used, and the got commit command may be used to commit
arbitrary changes to the temporary branch while the histedit operation is
interrupted.

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.

-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 are 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.

Both branches can be considered equivalent after integration since they will be
pointing at the same commit. Both branches remain available for future work, if
desired. 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. 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, 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.

merge [-aCcn] [branch]
(alias: mg)
Create a merge commit based on the current branch of the work tree and the
specified branch. If a linear project history is desired, then use of got rebase
should be preferred over got merge. However, even strictly linear projects may
require merge commits in order to merge in new versions of third-party code stored
on vendor branches created with got import.

Merge commits are commits based on multiple parent commits. The tip commit of the
work tree's current branch, which must be set with got update -b before starting
the merge operation, will be used as the first parent. The tip commit of the
specified branch will be used as the second parent.

No ancestral relationship between the two branches is required. If the two
branches have already been merged previously, only new changes will be merged.

It is not possible to create merge commits with more than two parents. If more
than one branch needs to be merged, then multiple merge commits with two parents
each can be created in sequence.

While merging changes found on the branch into the work tree, show the status of
each affected file, using the following status codes:

If merge conflicts occur, the merge operation is interrupted and conflicts must be
resolved before the merge operation can continue. If any files with destined
changes are found to be missing or unversioned, or if files could not be deleted
due to differences in deleted content, the merge operation will be interrupted to
prevent potentially incomplete changes from being committed to the repository
without user intervention. The work tree may be modified as desired and the merge
can be continued once the changes present in the work tree are considered
complete. Alternatively, the merge operation may be aborted which will leave the
work tree's current branch unmodified.

If a merge conflict is resolved in a way which renders all merged changes into no-
op changes, the merge operation cannot continue and must be aborted.

got merge will refuse to run if certain preconditions are not met. If history of
the branch is based on the work tree's current branch, then no merge commit can be
created and got integrate may be used to integrate the branch instead. 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 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, 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 merge this branch.

The got update, got commit, got rebase, got histedit, got integrate, and got stage
commands will refuse to run while a merge operation is in progress. Other
commands which manipulate the work tree may be used for conflict resolution
purposes.

The options for got merge are as follows:

-a Abort an interrupted merge operation. If this option is used, no other
command-line arguments are allowed.

-C Allow a merge 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 merge operation. If this option is used, no other
command-line arguments are allowed.

-n Merge changes into the work tree as usual but do not create a merge commit
immediately. The merge result can be adjusted as desired before a merge
commit is created with got merge -c. Alternatively, the merge may be
aborted with got merge -a.

stage [-lpS] [-F response-script] [path ...]
(alias: sg)
Stage local changes for inclusion in the next commit. If no path is specified,
stage all changes in the work tree. Otherwise, stage changes at or within the
specified paths. Paths may be staged if they are added, modified, or deleted
according to got status.

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

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

Staged file contents are saved in newly created blob objects in the repository.
These blobs will be referred to by tree objects once staged changes have been
committed.

Staged changes affect the behaviour of got commit, got status, and got diff.
While paths with staged changes exist, the got commit command will refuse to
commit any paths which do not have staged changes. Local changes created on top
of staged changes can only be committed if the path is staged again, or if the
staged changes are committed first. The got status command will show both local
changes and staged changes. The got diff command is able to display local changes
relative to staged changes, and to display staged changes relative to the
repository. The got revert command cannot revert staged changes but may 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 which are already staged, along
with the IDs of staged blob objects and stage status codes. If paths were
provided on the command line, show the staged paths among the specified
paths. Otherwise, show all staged paths.

-p Instead of staging the entire content of a 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 which point outside of the path space that
is under version control. By default, got stage will reject such symbolic
links due to safety concerns. As a precaution, got may decide to
represent such a symbolic link as a regular file which contains 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 stage will refuse to run if certain preconditions are not met. If a file
contains merge conflicts, these conflicts must be resolved first. If a file is
found to be 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 (however,
this does not prevent the file from becoming out-of-date at some point after
having been staged).

The got update, got rebase, and got histedit commands will refuse to run while
staged changes exist. If staged changes cannot 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 may then be staged again if necessary.

unstage [-p] [-F response-script] [path ...]
(alias: ug)
Merge staged changes back into the work tree and put affected paths back into non-
staged status. If no path is specified, unstage all staged changes across the
entire work tree. Otherwise, unstage changes at or within the specified paths.

Show the status of each affected file, using the following status 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 Instead of unstaging the entire content of a changed file, interactively
select or reject changes for unstaging based on “y” (unstage change), “n”
(keep change staged), and “q” (quit unstaging this file) responses. 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.

cat [-P] [-c commit] [-r repository-path] arg ...
Parse and print 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.

Attempt to interpret each argument as a reference, a tag name, or an object ID
SHA1 hash. 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 SHA1
hash automatically, provided the abbreviation is unique.

If none of the above interpretations produce a valid result, or if the -P option
is used, 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 SHA1 hash or an existing reference or
tag name which will be resolved to a commit ID. An abbreviated hash
argument will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique.

-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.

info [path ...]
Display meta-data stored in a work tree. See got-worktree(5) for details.

The work tree to use is resolved implicitly by walking upwards from the current
working directory.

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.

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, 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.

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.

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.

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.

EXIT STATUS

     The got utility exits 0 on success, and >0 if an error occurs.

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

     Use of HTTP URLs currently requires git(1):

           $ cd /var/git/
           $ git clone --bare 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:

           $ gotadmin 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

     While operating inside a work tree, paths are specified relative to the current working
     directory, so this command will log the subdirectory sys/uvm:

           $ cd sys/uvm && got log .

     And this command has the same effect:

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

     And this command displays work tree meta-data about all tracked files:

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

     Add new files and remove obsolete files in a work tree directory:

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

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

           $ got commit -m 'unify the buffer cache'

     Alternatively, create a new commit from local changes in a work tree directory with a log
     message that has been prepared 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 the
     rolled-back change into the work tree as a local change to be amended and perhaps committed
     again:

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

     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

     In a repository created with a HTTP URL and git clone --bare the git-fetch(1) command must
     be used instead:

           $ cd /var/git/src.git
           $ git fetch origin master:refs/remotes/origin/master

     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

     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.  This can be achieved
     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, the following git-fetch(1) configuration item can be added 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.  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.

     got rebase must 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 must first 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

     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

     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 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.

AUTHORS

     Anthony J. Bentley <bentley@openbsd.org>
     Christian Weisgerber <naddy@openbsd.org>
     Hiltjo Posthuma <hiltjo@codemadness.org>
     Josh Rickmar <jrick@zettaport.com>
     Joshua Stein <jcs@openbsd.org>
     Klemens Nanni <kn@openbsd.org>
     Martin Pieuchot <mpi@openbsd.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>
     Theo Buehler <tb@openbsd.org>
     Thomas Adam <thomas@xteddy.org>
     Tracey Emery <tracey@traceyemery.net>
     Yang Zhong <yzhong@freebsdfoundation.org>

     Parts of got, tog(1), and gotwebd(8) were derived from code under copyright by:

     Caldera International
     Daniel Hartmeier
     Esben Norby
     Henning Brauer
     Håkan Olsson
     Ingo Schwarze
     Jean-Francois Brousseau
     Joris Vink
     Jyri J. Virkki
     Larry Wall
     Markus Friedl
     Niall O'Higgins
     Niklas Hallqvist
     Ray Lai
     Ryan McBride
     Theo de Raadt
     Todd C. Miller
     Xavier Santolaria

     got contains code contributed to the public domain by
     Austin Appleby.

CAVEATS

     got is a work-in-progress and some features remain to be implemented.

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

     •   Reading from remote repositories over HTTP or HTTPS protocols requires git-clone(1) and
         git-fetch(1).

     •   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.

NAME

SYNOPSIS

DESCRIPTION

ENVIRONMENT

FILES

EXIT STATUS

EXAMPLES

SEE ALSO

AUTHORS

CAVEATS