| GOT(1) | General Commands Manual | GOT(1) |
got — Game of
Trees
got |
[-hV] command
[arg ...] |
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-V,
--versionThe commands for got are as follows:
import
[-b branch]
[-I pattern]
[-m message]
[-r repository-path]
directory(alias:
im)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-I
pattern-m
message-m option, got
import opens a temporary file in an editor where a log message
can be written. Quitting the editor without saving the file will abort
the import operation.-r
repository-pathclone
[-almqv] [-b
branch] [-R
reference] repository-URL
[directory](alias:
cl)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:
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:
-afetch_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-a option.-l-q and
-v.-mThe repository's got.conf(5) and
config files will be set up with the
“mirror” option enabled, such that
got fetch or git-fetch(1)
will write incoming changes directly to branches in the
“refs/heads/” reference namespace, rather than to
branches in the “refs/remotes/” namespace. This avoids
the usual requirement of having to run got
rebase or got merge after
got fetch in order to make incoming changes
appear on branches in the “refs/heads/” namespace. But
maintaining custom changes in the cloned repository becomes
difficult since such changes will be at risk of being discarded
whenever incoming changes are fetched.
-q-R
referenceEach 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.
-vgot 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)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 or got merge 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-b option.-b
branch-a
option.-dgotadmin cleanup.-l-v,
-q, and -r.-q-R
referenceEach 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-pathgot work tree, use the
repository path associated with this work tree.-t-vgot 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.-XWith -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
[-Eq] [-b
branch] [-c
commit] [-p
path-prefix] repository-path
[work-tree-path](alias:
co)| 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-c
commitThe expected commit argument is a
commit ID SHA1 hash, or a reference name or a keyword which will be
resolved to a commit ID. An abbreviated hash argument will be
expanded to a full SHA1 hash automatically, provided the
abbreviation is unique. The keywords ":base" and
":head" resolve to the repository's HEAD reference, or, if
the -b option is used, the head of the
checked-out branch. Keywords and reference
names may be appended with ":+" or ":-"
modifiers and an optional integer N to denote the Nth descendant or
antecedent by first parent traversal, respectively; for example,
:head:-2 denotes the work tree branch head's 2nd
generation ancestor, and foo:-3 will denote the
3rd generation ancestor of the commit resolved by the
"foo" reference. If an integer does not follow the
":+" or ":-" modifier, a "1" is
implicitly appended (e.g., :head:- is equivalent
to :head:-1).
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-p
path-prefix-qupdate
[-q] [-b
branch] [-c
commit] [path ...](alias:
up)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
branchAs 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
commitThe expected commit argument is a commit ID SHA1 hash, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. Keywords and reference names may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent, respectively, by first parent traversal; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, foo:-3 will denote the 3rd generation ancestor of the commit resolved by the "foo" reference. If an integer does not follow the ":+" or ":-" modifier, a "1" is implicitly appended (e.g., :head:- is equivalent to :head:-1).
-qstatus
[-I] [-S
status-codes] [-s
status-codes] [path ...](alias:
st)| 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-S
status-codes-s
option.-s
status-codes-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]The options for got log are as
follows:
-bgot log shows
the linear history of the current branch only.-C
number-p. By default, 3 lines of context are
shown.-c
commitThe expected commit argument is a commit ID SHA1 hash, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and references may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent, respectively, by first parent traversal; for example, :head:-2 denotes the HEAD reference's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, bar:+3 will denote the 3rd generation descendant of the commit resolved by the "bar" reference. A ":+" or ":-" modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).
-d-s option. Implies the
-P option (diffstat displays a list of changed
paths).-l
NGOT_LOG_DEFAULT_LIMIT environment variable may
be set to change this default value.-P| 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-s option.-R-r
repository-pathgot work tree, use the
repository path associated with this work tree.-S
search-pattern-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-p or -P option.-x
commit-c, the expected commit
argument is a commit ID SHA1 hash, or a reference name or a keyword
which will be resolved to a commit ID. This option has no effect if
the specified commit is never traversed.diff
[-adPsw] [-C
number] [-c
commit] [-r
repository-path] [object1
object2 | path ...](alias:
di)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-C
number-c
commitIf the -c option is used, all
non-option arguments will be interpreted as paths. If one or more
such path arguments are provided, only show
differences for the specified paths.
The expected commit argument is a commit ID SHA1 hash, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and references may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent, respectively, by first parent traversal; for example, :head:-2 denotes the HEAD reference's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, baz:+8 will denote the 8th generation descendant of the commit resolved by the "baz" reference. If an integer does not follow the ":+" or ":-" modifier, a "1" is implicitly appended (e.g., :head:- is equivalent to :head:-1).
Cannot be used together with the
-P option.
-d-Pgot diff is invoked in a work tree.-r
repository-pathgot work tree, use the
repository path associated with this work tree.-sgot stage instead of
showing local changes in the work tree. This option is only valid when
got diff is invoked in a work tree.-wblame
[-c commit]
[-r repository-path]
path(alias:
bl)The options for got blame are as
follows:
-c
commit-r
repository-pathgot work tree, use the
repository path associated with this work tree.tree
[-iR] [-c
commit] [-r
repository-path] [path](alias:
tr)| @ | 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
commitThe expected argument is a commit ID SHA1 hash, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and references may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, spam:-3 will denote the 3rd generation ancestor of the commit resolved by the "spam" reference. A ":+" or ":-" modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).
-i-R-r
repository-pathgot work tree, use the
repository path associated with this work tree.ref
[-dlt] [-c
object] [-r
repository-path] [-s
reference] [name]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
objectThe expected object argument is an ID SHA1 hash or an existing reference or tag name or a keyword which will be resolved to the ID of a corresponding commit, tree, tag, or blob object. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and reference names may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and tagged:-3 will denote the 3rd generation ancestor of the commit resolved by the "tagged" reference. If an integer does not follow the ":+" or ":-" modifier, a "1" is implicitly appended (e.g., :head:- is equivalent to :head:-1).
Cannot be used together with any other options except
-r.
-dgotadmin
cleanup. Cannot be used together with any other options except
-r.-l-r and
-t.-r
repository-pathgot work tree, use the
repository path associated with this work tree.-s
reference-r.-t-l option to be used as
well.branch
[-lnt] [-c
commit] [-d
name] [-r
repository-path] [name](alias:
br)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-d
nameOnly 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.
-lIf invoked in a work tree, the work tree's current branch is shown with one of the following annotations:
| * | work tree's base commit and the base commit of all tracked files matches the branch tip |
| ~ | work tree comprises mixed commits or its base commit is out-of-date |
-n-r
repository-pathgot work tree, use the
repository path associated with this work tree.-t-l option to be used as
well.tag
[-lVv] [-c
commit] [-m
message] [-r
repository-path] [-s
signer-id] nameTags 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-l-m
message-m option, got tag
opens a temporary file in an editor where a tag message can be
written. Quitting the editor without saving the file will abort the
tag operation.-r
repository-pathgot work tree, use the
repository path associated with this work tree.-s
signer-idFor 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).
-Vgot 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.
-vBy 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 ...got
status ignore pattern will not be added.
If a path mentioned in the command line
is not an unversioned file then got add may
raise an error. To avoid unnecessary errors from paths picked up by file
globbing patterns in the shell, paths in the argument list will be
silently ignored if they are not reported by got
status at all, or if they are reported with one of the following
status codes and do not have changes staged via got
stage:
| M | modified file |
| A | file scheduled for addition in next commit |
| C | modified or added file which contains merge conflicts |
| m | modified file modes (executable bit only) |
The options for got add are as
follows:
remove
[-fkR] [-s
status-codes] path ...(alias:
rm)The options for got remove are as
follows:
-f-k-Rgot remove will refuse to run if a specified
path is a directory.-s
status-codes| 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)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
commitIf 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.
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.
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.
The expected commit argument is a commit ID SHA1 hash, or a reference name or a keyword which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. Keywords and references may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, flan:+3 will denote the 3rd generation descendant of the commit resolved by the "flan" reference. A ":+" or ":-" modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).
-n-p
strip-count-p option is not used, ‘a/’ and
‘b/’ path prefixes generated by
git-diff(1) will be recognized and stripped
automatically.-Rrevert
[-pR] [-F
response-script] path ...(alias:
rv)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-p option, read “y”,
“n”, and “q” responses line-by-line from
the specified response-script file instead of
prompting interactively.-p-Rgot revert will refuse to run if a specified
path is a directory.commit
[-CNnS] [-A
author] [-F
path] [-m
message] [path ...](alias:
ci)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. Quitting the editor without saving the file will abort
the commit operation.
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
authorGOT_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.
-CCommitting 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
pathgot 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-F option.-Ngot 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.-ngot commit from
generating a diff of the to-be-committed changes in a temporary file
which can be viewed while editing a commit message.-Sgot
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)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-a option is equivalent to listing all
branches with multiple -b options. Cannot be
used together with the -b option.-b
branch-a
option.-d
branchOnly 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.
-fgot fetch
followed by got rebase or got
merge would usually be required before changes can be sent. The
server may reject forced requests regardless, depending on its
configuration.
Any commit, tree, tag, and blob objects belonging to overwritten branches or tags may become subject to deletion by Git's garbage collector running on the server.
The “refs/tags” reference namespace is
globally shared between all repositories. Use of the
-f option to overwrite tags is discouraged
because it can lead to inconsistencies between the tags present in
different repositories. In general, creating a new tag with a
different name is recommended instead of overwriting an existing
tag.
Use of the -f option is
particularly discouraged if changes being sent are based on an
out-of-date copy of a branch in the remote repository. Instead of
using the -f option, new changes should be
fetched with got fetch and local branches
should be rebased with got rebase or merged
with got merge, followed by another attempt
to send the changes.
The -f option should only be
needed in situations where the remote repository's copy of a branch
or tag is known to be out-of-date and is considered disposable. The
risks of creating inconsistencies between different repositories
should also be taken into account.
-q-r
repository-pathgot work tree, use the
repository path associated with this work tree.-T-T option is equivalent to listing all tags
with multiple -t options. Cannot be used
together with the -t option.-t
tag-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.
-vgot 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)The expected argument is a commit ID SHA1 hash, or a reference name or keyword 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. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. Keywords and references may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, barbaz:+3 will denote the 3rd generation descendant of the commit resolved by the "barbaz" reference. A ":+" or ":-" modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).
Show the status of each affected file, using the following status codes:
| G | file was merged |
| C | file was merged and conflicts occurred during merge |
| ! | changes destined for a missing file were not merged |
| D | file was deleted |
| d | file's deletion was prevented by local modifications |
| A | new file was added |
| ~ | changes destined for a non-regular file were not merged |
| ? | changes destined for an unversioned file were not merged |
The 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:
-lIf 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.
-XIf 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)The expected argument is a commit ID SHA1 hash, or a reference name or keyword 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. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. Keywords and references may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, wip:+5 will denote the 5th generation descendant of the commit resolved by the "wip" reference. A ":+" or ":-" modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).
Show the status of each affected file, using the following status codes:
| G | file was merged |
| C | file was merged and conflicts occurred during merge |
| ! | changes destined for a missing file were not merged |
| D | file was deleted |
| d | file's deletion was prevented by local modifications |
| A | new file was added |
| ~ | changes destined for a non-regular file were not merged |
| ? | changes destined for an unversioned file were not merged |
The reverse-merged changes will appear as local changes in the
work tree, which may be viewed with got diff,
amended manually or with further got backout
commands, committed with got commit.
If invoked in a work tree where no
rebase, histedit, or
merge operation is taking place,
got backout creates a record of commits which
have been reverse-merged into the work tree. When a file changed by
got backout is committed with
got commit, the log messages of relevant
reverse-merged commits will then appear in the editor, where the
messages should be further adjusted to convey the reasons for backing
out the changes. Upon exiting the editor, if the time stamp of the log
message file is unchanged or the log message is empty,
got commit will fail with an unmodified or empty
log message error.
If all the changes in all files touched by a given commit are
discarded, e.g. with got revert, this commit's
log message record will also disappear.
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:
-lIf 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.
-XIf 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)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:
| G | file was merged |
| C | file was merged and conflicts occurred during merge |
| ! | changes destined for a missing file were not merged |
| D | file was deleted |
| d | file's deletion was prevented by local modifications |
| A | new file was added |
| ~ | changes destined for a non-regular file were not merged |
| ? | changes destined for an unversioned file were not merged |
If merge conflicts 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-C-c option.-c-C.-lDisplay 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.
-XIf 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)The got histedit command requires the
GOT_AUTHOR environment variable to be set,
unless an author has been configured in got.conf(5) or
Git's user.name and
user.email configuration settings can be
obtained from the repository's .git/config file
or from Git's global ~/.gitconfig configuration
file.
Before starting a histedit operation,
the work tree's current branch must be set with got
update -b to the branch which should be edited, unless this
branch is already the current branch of the work tree. The tip of this
branch represents the upper bound (inclusive) of commits touched by the
histedit operation.
Furthermore, the work tree's base commit must be set with
got update -c to a point in this branch's commit
history where editing should begin. This commit represents the lower
bound (non-inclusive) of commits touched by the
histedit operation.
Editing of commit history is controlled via a
histedit script which can be written in an editor
based on a template, passed on the command line, or generated with the
-d, -e,
-f, or -m options.
Quitting the editor without saving the file will abort the histedit
operation.
The format of the histedit script is line-based. Each line in the script begins with a command name, followed by whitespace and an argument. For most commands, the expected argument is a commit ID 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
commit |
Open an editor to create a new log message for this commit. |
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:
| G | file was merged |
| C | file was merged and conflicts occurred during merge |
| ! | changes destined for a missing file were not merged |
| D | file was deleted |
| d | file's deletion was prevented by local modifications |
| A | new file was added |
| ~ | changes destined for a non-regular file were not merged |
| ? | changes destined for an unversioned file were not merged |
If merge conflicts 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-C-c option.-c-C.-d-d option
can only be used when starting a new histedit operation. If this
option is used, no other command-line arguments are allowed.-eedit 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-f-f option can
only be used when starting a new histedit operation. If this option is
used, no other command-line arguments are allowed.-lDisplay 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-m option can
only be used when starting a new histedit operation. If this option is
used, no other command-line arguments are allowed.-XIf 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)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
[-aCcMn] [branch](alias:
mg)Merge commits are commits based on multiple parent commits.
The tip commit of the work tree's current branch will be used as the
first parent. The tip commit of the specified
branch will be used as the second parent. The work
tree's current branch must be in the “refs/heads/”
reference namespace and can be set with got update
-b before starting the merge
operation.
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.
If a linear project history is desired, then use of
got rebase should generally be preferred over
got merge. However, even strictly linear
projects may require occasional merge commits, for example in order to
merge in new versions of third-party code stored on
“vendor” branches created with got
import.
While merging changes found on the branch into the work tree, 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 |
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.
got merge 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 then the work
tree must first be switched to a branch in the
“refs/heads/” namespace with got update
-b. 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-C-c option.-c-C.-M-ngot merge -c.
Alternatively, the merge may be aborted with got
merge -a.stage
[-lpS] [-F
response-script] [path ...](alias:
sg)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-p option, read “y”,
“n”, and “q” responses line-by-line from
the specified response-script file instead of
prompting interactively.-l-p-Sgot
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, got merge, 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)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-p option, read “y”,
“n”, and “q” responses line-by-line from
the specified response-script file instead of
prompting interactively.-pcat
[-P] [-c
commit] [-r
repository-path] arg ...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
commitThe expected argument is a commit ID SHA1 hash, or a reference name or keyword 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. The keywords ":base" and ":head" resolve to the work tree's base commit and branch head, respectively. The former is only valid if invoked in a work tree, while the latter will resolve to the tip of the work tree's current branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD reference. Keywords and references may be appended with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or antecedent by first parent traversal, respectively; for example, :head:-2 denotes the work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of the work tree's base commit. Similarly, quux:-8 will denote the 8th generation ancestor of the commit resolved by the "quux" reference. A ":+" or ":-" modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).
-P-r
repository-pathgot work tree, use the
repository path associated with this work tree.info
[path ...]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.
GOT_AUTHORgot commit, got
import, got rebase, got
merge, and got histedit commands. Because
git(1) may fail to parse commits without an email
address in author data, got attempts to reject
GOT_AUTHOR environment variables with a missing
email address.
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_GITCONFIGGOT_LOG_DEFAULT_LIMITgot 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,
EDITORgot commit,
got histedit, got import,
or got tag. If not set, the
vi(1) text editor will be spawned.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.
If present, a got.conf(5) configuration file in the
.got meta-data directory of a work tree supersedes
any relevant settings in the repository's got.conf(5)
configuration file and Git's config file.The got utility exits 0 on success,
and >0 if an error occurs.
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.gitUnfortunately, many of the popular Git hosting sites do not offer anonymous access via SSH. Such sites will require an account to be created, and a public SSH key to be uploaded to this account, before repository access via ssh:// URLs will work.
Use of HTTP URLs currently requires git(1):
$ cd /var/git/$ git clone --bare
https://github.com/openbsd/src.gitAlternatively, 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/srcCheck out a work tree from the Git repository to /usr/src:
$ got checkout /var/git/src.git
/usr/srcView local changes in a work tree directory:
$ got diff | lessIn 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 -lAs above, but list the most recently modified branches only:
$ got branch -lt | headIn 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-cacheSwitch 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-cacheCreate 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 commitIn 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 3As above, but display changes in the order in which patch(1) could apply them in sequence:
$ got log -p -l 3 -RIn a work tree or a git repository directory, log the history of a subdirectory:
$ got log sys/uvmWhile 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
../../uvmAnd this command displays work tree meta-data about all tracked files:
$ cd /usr/src$ got info . |
lessAdd new files and remove obsolete files in a work tree directory:
$ got add
sys/uvm/uvm_ubc.c$ got remove
sys/uvm/uvm_vnode.cCreate 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/msgUpdate any work tree checked out from the “unified-buffer-cache” branch to the latest commit on this branch:
$ got updateRoll 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-cacheFetch new changes on the remote repository's “master” branch, making them visible on the local repository's “origin/master” branch:
$ cd /usr/src$ got fetchIn 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/masterRebase 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 masterRebase the “unified-buffer-cache” branch on top of the new head commit of the “master” branch.
$ got update -b master$ got rebase
unified-buffer-cacheCreate 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.diffEdit the entire commit history of the “unified-buffer-cache” branch:
$ got update -b
unified-buffer-cache$ got update -c master$ got histeditBefore 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
falseAlternatively, 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 = falseThis 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 |
lessAs 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 can be used to merge changes
which are visible on the “origin/master” branch into the
“master” branch. This will also merge local changes, if any,
with the incoming changes:
$ got update -b
origin/master$ got rebase masterIn order to make changes committed to the “unified-buffer-cache” visible on the “master” branch, the “unified-buffer-cache” branch can be rebased onto the “master” branch:
$ got update -b master$ got rebase
unified-buffer-cacheChanges 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-cacheOn 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 -mIf 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
originIf the remote repository requires the HTTPS protocol, the git-push(1) command must be used instead:
$ cd /var/git/src.git$ git push origin masterWhen 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
originThe 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
originIn addition to reviewing the pull request in the web user interface, Jelmer can fetch the pull request's branch into his local repository and create a local branch which contains the proposed changes:
$ got fetch -R refs/pull/1046/head
origin$ got branch -c
refs/remotes/origin/pull/1046/head pr1046Once Jelmer has accepted the pull request, Stefan can fetch the merged changes, and possibly several other new changes, by running:
$ got fetch upstreamThe 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 masterAs an alternative to got rebase, branches
can be merged with got merge:
$ got update -b master$ got merge
upstream/masterThe question of whether to rebase or merge branches is philosophical. When in doubt, refer to the software project's policies set by project maintainers.
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
originIf 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.
gotadmin(1), tog(1), git-repository(5), got-worktree(5), got.conf(5), gotwebd(8)
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.
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:
got will not automatically merge changes to new
locations and git(1) will usually produce better
results.| January 31, 2025 | Debian |