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 worktree which can be placed at an arbitrary directory in the filesystem hierarchy. The on-
disk format of this work tree is described in got-worktree(5).
The got utility provides global and command-specific options. Global options must precede the command
name, and are as follows:
-h Display usage information and exit immediately.
-V, --version
Display program version and exit immediately.
The got utility only provides commands needed to perform version control tasks. Commands needed for
repository maintenance tasks are provided by gotadmin(1). Git repository server functionality is
provided by gotd(8). A repository interface for web browsers is provided by gotwebd(8). An interactive
repository interface for the terminal is provided by tog(1).
The commands for got are as follows:
init [-Ahashing-algorithm] [-bbranch] repository-path
Create a new empty repository at the specified repository-path.
After gotinit, the new repository must be populated before gotcheckout can be used. The gotimport command can be used to populate the new repository with data from a local directory.
Alternatively, on a server running gotd(8), the new repository can be made available to got(1)
or git(1) clients by adding the repository to gotd.conf(5) and restarting gotd(8). Clients may
then clone the new repository from the server, populate the cloned repository, and then
populate the new repository on the server via gotsend or gitpush.
The options for gotinit are as follows:
-Ahashing-algorithm
Configure the repository's hashing-algorithm used for the computation of Git object
IDs. Possible values are sha1 (the default) or sha256.
-bbranch
Make the repository's HEAD reference point to the specified branch instead of the
default branch “main”.
The gotinit command is equivalent to gotadmininit.
import [-bbranch] [-Ipattern] [-mmessage] [-rrepository-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 gotimport 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 gotimport are as follows:
-bbranch
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.
-Ipattern
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.
-mmessage
Use the specified log message when creating the new commit. Without the -m option, gotimport 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.
-rrepository-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] [-bbranch] [-iidentity-file] [-Jjumphost] [-Rreference] 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. gotclone 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.
ssh The Git protocol wrapped in an authenticated and encrypted ssh(1) tunnel. With this
protocol the hostname may contain an embedded username for ssh(1) to use: user@hostname
http The “smart” Git HTTP protocol. Not compatible with servers using the “dumb” Git HTTP
protocol.
The “smart” Git HTTP protocol is supported by gotclone and gotfetch, but not by gotsend. Sending from a repository cloned over HTTP will require use of a send block in
got.conf(5) to ensure that the “ssh://” protocol will be used by gotsend.
Use of this protocol is discouraged since it supports neither authentication nor
encryption.
https The “smart” Git HTTP protocol wrapped in SSL/TLS.
Objects in the cloned repository are stored in a pack file which is downloaded from the server.
This pack file will then be indexed to facilitate access to the objects stored within. If any
objects in the pack file are stored in deltified form, all deltas will be fully resolved in
order to compute the ID of such objects. This can take some time. More details about the pack
file format are documented in git-repository(5).
gotclone 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
gotfetch or git-fetch(1).
The options for gotclone 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
gotfetch. 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.
-bbranch
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.
-iidentity-file
Specify an identity-file, containing a private SSH key, to use with SSH connections.
The same option will be passed to ssh(1).
-Jjumphost
Specify a jumphost to use with SSH connections. The same option will be passed to
ssh(1).
-l List branches and tags available for fetching from the remote repository and exit
immediately. Cannot be used together with any of the other options except -q and -v.
-m Create the cloned repository as a mirror of the original repository. This is useful if
the cloned repository will not be used to store locally created commits.
The repository's got.conf(5) and config files will be set up with the “mirror” option
enabled, such that gotfetch 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 gotrebase or gotmerge after gotfetch 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.
-Rreference
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.
gotclone will refuse to fetch references from the remote repository's “refs/remotes/”
or “refs/got/” namespace.
-v Verbose mode. Causes gotclone 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] [-bbranch] [-iidentity-file] [-Jjumphost] [-Rreference] [-rrepository-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 gotclone.
By default, any branches configured in got.conf(5) for the remote-repository will be fetched.
If gotfetch 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. Over time,
small pack files will accumulate as a result of repeatedly running gotfetch. For best
performance, multiple small pack files can be combined into a single larger pack file with
gotadmincleanup. The number of pack files in the repository is displayed by gotadmininfo.
By default, branch references in the “refs/remotes/” reference namespace will be updated to
point at the newly fetched commits. The gotrebase or gotmerge 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 gotclone-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 gotadmincleanup. 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 gotfetch 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.
-bbranch
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. Cannot be used together with the -a 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 gotadmincleanup.
-iidentity-file
Specify an identity-file, containing a private SSH key, to use with SSH connections.
The same option will be passed to ssh(1).
-Jjumphost
Specify a jumphost to use with SSH connections. The same option will be passed to
ssh(1).
-l List branches and tags available for fetching from the remote repository and exit
immediately. Cannot be used together with any of the other options except -v, -q, and
-r.
-q Suppress progress reporting output. The same option will be passed to ssh(1) if
applicable.
-Rreference
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 local repository's “refs/remotes/” namespace,
unless the local repository was created as a mirror with gotclone-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 gotbranch
if needed.
gotfetch will refuse to fetch references from the remote repository's “refs/remotes/”
or “refs/got/” namespace.
-rrepository-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 gotfetch 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 gotadmincleanup and Git's garbage collector.
checkout [-Eq] [-bbranch] [-ccommit] [-ppath-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 worktreepath is not specified, either use the last component of repositorypath, or if
a pathprefix was specified use the last component of pathprefix.
The options for gotcheckout are as follows:
-bbranch
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.
-ccommit
Check out files from the specified commit on the selected branch. If this option is
not specified, the most recent commit on the selected branch will be used.
The expected commit argument is a commit ID, or a reference name or a keyword which
will be resolved to a commit ID. An abbreviated hash argument will be expanded to a
full commit ID automatically, provided the abbreviation is unique. The keywords
":base" and ":head" resolve to the 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 gotbranch before gotcheckout
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.
-ppath-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] [-bbranch] [-ccommit] [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 gotupdate is run again after merge conflicts have been
resolved. If the conflicting changes are no longer needed, affected files can be reverted with
gotrevert before running gotupdate 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 gotupdate across the entire work tree.
Specifying a path is incompatible with the -b option.
gotupdate cannot update paths with staged changes. If changes have been staged with gotstage, these changes must first be committed with gotcommit or unstaged with gotunstage.
The options for gotupdate are as follows:
-bbranch
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 gotcommit, or could be discarded
with gotrevert.
-ccommit
Update the work tree to the specified commit. If this option is not specified, the
most recent commit on the work tree's branch will be used.
The expected commit argument is a commit ID, or a reference name or a keyword which
will be resolved to a commit ID. An abbreviated hash argument will be expanded to a
full commit ID automatically, provided the abbreviation is unique. The keywords
":base" and ":head" resolve to the work tree's base commit and branch head,
respectively. Keywords and reference names may be appended with ":+" or ":-" modifiers
and an optional integer N to denote the Nth descendant or antecedent, respectively, by
first parent traversal; for example, :head:-2 denotes the work tree branch head's 2nd
generation ancestor, and :base:+4 denotes the 4th generation descendant of the work
tree's base commit. Similarly, foo:-3 will denote the 3rd generation ancestor of the
commit resolved by the "foo" reference. If an integer does not follow the ":+" or ":-"
modifier, a "1" is implicitly appended (e.g., :head:- is equivalent to :head:-1).
-q Silence progress output.
status [-I] [-Sstatus-codes] [-sstatus-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 gotstage, 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
If the work tree contains the results of an interrupted gotrebase, gothistedit, or gotmerge
operation then display a message which shows the branches involved.
The options for gotstatus are as follows:
-I Show unversioned files even if they match an ignore pattern.
-Sstatus-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.
-sstatus-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), gotstatus 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, gotstatus supports consecutive asterisks, “**”, which
will match an arbitrary amount of directories. Unlike cvs(1), gotstatus only supports a
single ignore pattern per line. Unlike git(1), gotstatus does not support negated ignore
patterns prefixed with “!”, and gives no special significance to the location of path component
separators, “/”, in a pattern.
log [-bdPpRst] [-Cnumber] [-ccommit] [-lN] [-rrepository-path] [-Ssearch-pattern] [-xcommit] [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 gotlog are as follows:
-b Display individual commits which were merged into the current branch from other
branches. By default, gotlog shows the linear history of the current branch only.
-Cnumber
Set the number of context lines shown in diffs with -p. By default, 3 lines of context
are shown.
-ccommit
Start traversing history at the specified commit. 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.
The expected commit argument is a commit ID, or a reference name or a keyword which
will be resolved to a commit ID. An abbreviated hash argument will be expanded to a
full commit ID automatically, provided the abbreviation is unique. The keywords
":base" and ":head" resolve to the work tree's base commit and branch head,
respectively. The former is only valid if invoked in a work tree, while the latter
will resolve to the tip of the work tree's current branch if invoked in a work tree,
otherwise it will resolve to the repository's HEAD reference. Keywords and references
may be appended with ":+" or ":-" modifiers and an optional integer N to denote the 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 Display diffstat of changes introduced in each commit. Cannot be used with the -s
option. Implies the -P option (diffstat displays a list of changed paths).
-lN 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.
-rrepository-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.
-Ssearch-pattern
If specified, show only commits with a log message, author name, committer name, or
commit ID matched by the extended regular expression search-pattern. Lines in
committed patches will be matched if -p is specified. File paths changed by a commit
will be matched if -P is specified. 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.
-t Display commits in topological order. This option has no effect without the -b option
because a linear history is sorted in topological order by definition. Topological
sorting is disabled by default because the present implementation requires that commit
history is fully traversed before any output can be shown.
-xcommit
Stop traversing commit history immediately after the specified commit has been
traversed. Like -c, the expected commit argument is a commit ID, or a reference name
or a keyword which will be resolved to a commit ID. This option has no effect if the
specified commit is never traversed.
diff [-adPsw] [-Cnumber] [-ccommit] [-rrepository-path] [object1object2 | 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,
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
commit ID automatically, provided the abbreviation is unique. If none of these interpretations
produce a valid result or if the -P option is used, and if gotdiff is running in a work tree,
attempt to interpret the two arguments as paths.
The options for gotdiff are as follows:
-a Treat file contents as ASCII text even if binary data is detected.
-Cnumber
Set the number of context lines shown in the diff. By default, 3 lines of context are
shown.
-ccommit
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.
If the -c option is used, all non-option arguments will be interpreted as paths. If
one or more such path arguments are provided, only show differences for the specified
paths.
The expected commit argument is a commit ID, or a reference name or a keyword which
will be resolved to a commit ID. An abbreviated hash argument will be expanded to a
full commit ID automatically, provided the abbreviation is unique. The keywords
":base" and ":head" resolve to the work tree's base commit and branch head,
respectively. The former is only valid if invoked in a work tree, while the latter
will resolve to the tip of the work tree's current branch if invoked in a work tree,
otherwise it will resolve to the repository's HEAD reference. Keywords and references
may be appended with ":+" or ":-" modifiers and an optional integer N to denote the 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 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 gotdiff is invoked in a work tree.
-rrepository-path
Use the repository at the specified path. If not specified, assume the repository is
located at or above the current working directory. If this directory is a got work
tree, use the repository path associated with this work tree.
-s Show changes staged with gotstage instead of showing local changes in the work tree.
This option is only valid when gotdiff is invoked in a work tree.
-w Ignore whitespace-only changes.
blame [-ccommit] [-rrepository-path] path
(alias: bl)
Display line-by-line history of a file at the specified path.
The options for gotblame are as follows:
-ccommit
Start traversing history at the specified commit. The expected argument is a commit
ID, or a reference name or a keyword which will be resolved to a commit ID. An
abbreviated hash argument will be expanded to a full commit ID automatically, provided
the abbreviation is unique. The keywords ":base" and ":head" resolve to the work
tree's base commit and branch head, respectively. The former is only valid if invoked
in a work tree, while the latter will resolve to the tip of the work tree's current
branch if invoked in a work tree, otherwise it will resolve to the repository's HEAD
reference. Keywords and references may be appended with ":+" or ":-" modifiers and an
optional integer N to denote the 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, xyz:-5 will denote the 5th generation ancestor of the
commit resolved by the "xyz" reference. A ":+" or ":-" modifier without a trailing
integer has an implicit "1" appended (e.g., :base:+ is equivalent to :base:+1).
-rrepository-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.
tree [-iR] [-ccommit] [-rrepository-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 gottree are as follows:
-ccommit
List files and directories as they appear in the specified commit.
The expected argument is a commit ID, or a reference name or a keyword which will be
resolved to a commit ID. An abbreviated hash argument will be expanded to a full
commit ID automatically, provided the abbreviation is unique. The keywords ":base" and
":head" resolve to the work tree's base commit and branch head, respectively. The
former is only valid if invoked in a work tree, while the latter will resolve to the
tip of the work tree's current branch if invoked in a work tree, otherwise it will
resolve to the repository's HEAD reference. Keywords and references may be appended
with ":+" or ":-" modifiers and an optional integer N to denote the 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 Show object IDs of files (blob objects) and directories (tree objects).
-R Recurse into sub-directories in the repository.
-rrepository-path
Use the repository at the specified path. If not specified, assume the repository is
located at or above the current working directory. If this directory is a got work
tree, use the repository path associated with this work tree.
ref [-dlt] [-cobject] [-rrepository-path] [-sreference] [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 gotref are as follows:
-cobject
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 an object ID or an existing reference or tag name or a
keyword which will be resolved to the ID of a corresponding commit, tree, tag, or blob
object. An abbreviated hash argument will be expanded to a full commit ID
automatically, provided the abbreviation is unique. The keywords ":base" and ":head"
resolve to the work tree's base commit and branch head, respectively. The former is
only valid if invoked in a work tree, while the latter will resolve to the tip of the
work tree's current branch if invoked in a work tree, otherwise it will resolve to the
repository's HEAD reference. Keywords and reference names may be appended with ":+" or
":-" modifiers and an optional integer N to denote the 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.
-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 gotadmincleanup. 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.
-rrepository-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.
-sreference
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] [-ccommit] [-dname] [-rrepository-path] [name]
(alias: br)
Create, list, or delete branches.
Local branches are managed via references which live in the “refs/heads/” reference namespace.
The gotbranch 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
gotupdate-bname 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 gotbranch are as follows:
-ccommit
Make a newly created branch reference point at the specified commit. The expected
argument is a commit ID, or a reference name or keyword which will be resolved to a
commit ID. An abbreviated hash argument will be expanded to a full commit ID
automatically, provided the abbreviation is unique. The keywords ":base" and ":head"
resolve to the work tree's base commit and branch head, respectively. The former is
only valid if invoked in a work tree, while the latter will resolve to the tip of the
work tree's current branch if invoked in a work tree, otherwise it will resolve to the
repository's HEAD reference. Keywords and references may be appended with ":+" or ":-"
modifiers and an optional integer N to denote the Nth descendant or antecedent by first
parent traversal, respectively; for example, :head:-2 denotes the work tree branch
head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of
the work tree's base commit. Similarly, foobar:+3 will denote the 3rd generation
descendant of the commit resolved by the "foobar" reference. A ":+" or ":-" modifier
without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to
:base:+1).
-dname
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 gotadmincleanup.
-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 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 Do not switch and update the work tree after creating a new branch.
-rrepository-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 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 [-lsVv] [-ccommit] [-mmessage] [-rrepository-path] [-Ssigner-id] name
Manage tags in a repository.
Tags are managed via references which live in the “refs/tags/” reference namespace. The gottag 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 gottag are as follows:
-ccommit
Make the newly created tag reference point at the specified commit. The expected
commit argument is a commit ID, or a reference or keyword which will be resolved to a
commit ID. An abbreviated hash argument will be expanded to a full commit ID
automatically, provided the abbreviation is unique. The keywords ":base" and ":head"
resolve to the work tree's base commit and branch head, respectively. The former is
only valid if invoked in a work tree, while the latter will resolve to the tip of the
work tree's current branch if invoked in a work tree, otherwise it will resolve to the
repository's HEAD reference. Keywords and references may be appended with ":+" or ":-"
modifiers and an optional integer N to denote the Nth descendant or antecedent by first
parent traversal, respectively; for example, :head:-2 denotes the work tree branch
head's 2nd generation ancestor, and :base:+4 denotes the 4th generation descendant of
the work tree's base commit. Similarly, eggs:-3 will denote the 3rd generation
ancestor of the commit resolved by the "eggs" reference. A ":+" or ":-" modifier
without a trailing integer has an implicit "1" appended (e.g., :base:+ is equivalent to
:base:+1).
-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.
-mmessage
Use the specified tag message when creating the new tag. Without the -m option, gottag 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.
-rrepository-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.
-Ssigner-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).
gottag will sign the tag object by invoking ssh-keygen(1) with the -Ysign command,
using the signature namespace “git” for compatibility with git(1).
-s Display a short one-line summary of each tag, instead of the default history format.
Can only be used with the -l option.
-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.
gottag verifies SSH-based signatures by invoking ssh-keygen(1) with the options -Yverify-fallowed_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 gottag command will not delete tags or change existing tags. If a tag must be
deleted, the gotref 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 gotstatus ignore pattern will not be added.
If a path mentioned in the command line is not an unversioned file then gotadd 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 gotstatus at all, or if they are reported with one of the following status codes and do not have
changes staged via gotstage:
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 gotadd are as follows:
-I Add files even if they match a gotstatus ignore pattern.
-R Permit recursion into directories. If this option is not specified, gotadd will
refuse to run if a specified path is a directory.
remove [-fkR] [-sstatus-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 gotremove 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, gotremove will
refuse to run if a specified path is a directory.
-sstatus-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] [-ccommit] [-pstrip-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 gotdiff, 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.
gotpatch 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 gotdiff and can be
reverted with gotrevert if needed.
The options for gotpatch are as follows:
-ccommit
Attempt to locate files within the specified commit for use as a merge-base for 3-way
merges.
If the -c option is not used then gotpatch will attempt to locate merge-bases via
object IDs found in patchfile meta-data, such as produced by gotdiff 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, or a reference name or a keyword which
will be resolved to a commit ID. An abbreviated hash argument will be expanded to a
full commit ID automatically, provided the abbreviation is unique. The keywords
":base" and ":head" resolve to the work tree's base commit and branch head,
respectively. Keywords and 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 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.
-pstrip-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] [-Fresponse-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 gotrevert!
If a file was added with gotadd, it will become an unversioned file again. If a file was
deleted with gotremove, it will be restored.
The options for gotrevert are as follows:
-Fresponse-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, gotrevert will
refuse to run if a specified path is a directory.
commit [-CNnS] [-Aauthor] [-Fpath] [-mmessage] [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 gotstage, only commit staged changes
and reject any specified paths which have not been staged.
gotcommit 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 gotupdate
across the entire work tree.
The gotcommit 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 gotcommit are as follows:
-Aauthor
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.
-Fpath
Use the prepared log message stored in the file found at path when creating the new
commit. gotcommit 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.
-mmessage
Use the specified log message when creating the new commit. Cannot be used together
with the -F option.
-N This option prevents gotcommit 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 gotcommit 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, gotcommit 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.
gotcommit 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, gotupdate
must be used first in order to merge local changes with changes made in the repository.
send [-afqTv] [-bbranch] [-dbranch] [-iidentity-file] [-Jjumphost] [-rrepository-path] [-ttag]
[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 gotclone.
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 gotfetch and local branches must be rebased with gotrebase before gotsend
can succeed. The -f option can be used to make exceptions to these requirements.
The options for gotsend 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.
-bbranch
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.
-dbranch
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 gotfetch followed by gotrebase or gotmerge 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 gotfetch and local branches should be rebased with
gotrebase or merged with gotmerge, 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.
-iidentity-file
Specify an identity-file, containing a private SSH key, to use with SSH connections.
The same option will be passed to ssh(1).
-Jjumphost
Specify a jumphost to use with SSH connections. The same option will be passed to
ssh(1).
-q Suppress progress reporting output. The same option will be passed to ssh(1) if
applicable.
-rrepository-path
Use the repository at the specified path. If not specified, assume the repository is
located at or above the current working directory. If this directory is a got work
tree, use the repository path associated with this work tree.
-T Attempt to send all tags from the local repository's “refs/tags/” reference namespace.
The -T option is equivalent to listing all tags with multiple -t options. Cannot be
used together with the -t option.
-ttag 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 gotsend 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 commit ID, or a reference name or keyword which will be resolved to
a commit ID. An abbreviated hash argument will be expanded to a full commit ID automatically,
provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work
tree's base commit and branch head, respectively. 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 gotdiff, amended manually or with further gotcherrypick commands, committed with gotcommit.
If invoked in a work tree where no rebase, histedit, or merge operation is taking place, gotcherrypick creates a record of commits which have been merged into the work tree. When a file
changed by gotcherrypick is committed with gotcommit, 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, gotcommit 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 gotrevert,
this commit's log message record will also disappear.
gotcherrypick 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 gotupdate. If any relevant files already contain merge conflicts, these conflicts must be
resolved first.
The options for gotcherrypick 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 commit ID, or a reference name or keyword which will be resolved to
a commit ID. An abbreviated hash argument will be expanded to a full commit ID automatically,
provided the abbreviation is unique. The keywords ":base" and ":head" resolve to the work
tree's base commit and branch head, respectively. 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 gotdiff, amended manually or with further gotbackout commands, committed with gotcommit.
If invoked in a work tree where no rebase, histedit, or merge operation is taking place, gotbackout creates a record of commits which have been reverse-merged into the work tree. When a
file changed by gotbackout is committed with gotcommit, 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, gotcommit 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 gotrevert,
this commit's log message record will also disappear.
gotbackout 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 gotupdate. If
any relevant files already contain merge conflicts, these conflicts must be resolved first.
The options for gotbackout 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 gotrebase 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 gotupdate-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 gotrebase-l command. Removal of these references makes objects which become unreachable via any
reference subject to removal by Git's garbage collector or gotadmincleanup.
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.
gotrebase 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 gotupdate. If changes have been staged with gotstage, these changes must first be
committed with gotcommit or unstaged with gotunstage. If the work tree contains local
changes, these changes must first be committed with gotcommit or reverted with gotrevert. 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 gotupdate, gotintegrate, gotmerge, gotcommit, and gothistedit 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 gotrebase will simply switch the work tree to the specified branch and
update files in the work tree accordingly.
The options for gotrebase are as follows:
-a Abort an interrupted rebase operation. If this option is used, no other command-line
arguments are allowed.
-C Allow a rebase operation to continue with files in conflicted status. This option
should generally be avoided, and can only be used with the -c option.
-c Continue an interrupted rebase operation. If this option is used, no other command-
line arguments are allowed except -C.
-l Show a list of past rebase operations, represented by references in the
“refs/got/backup/rebase” reference namespace.
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 gotlog command with the -c and -x options can be
used to examine the history of either version of the branch, and the gotbranch 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, gotrebase 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 gotadmincleanup.
If this option is used, gotrebase does not require a work tree. None of the other
options can be used together with -X.
histedit [-aCcdeflmX] [-Fhistedit-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 gothistedit 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 gotupdate-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 gotupdate-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 histeditscript which can be written in an editor
based on a template, passed on the command line, or generated with the -d, -e, -f, or -m
options. Quitting the editor without saving the file will abort the histedit operation.
The format of the histedit script is line-based. Each line in the script begins with a command
name, followed by whitespace and an argument. For most commands, the expected argument is a
commit ID. Any remaining text on the line is ignored. Lines which begin with the ‘#’
character are ignored entirely.
The available histedit script commands are as follows:
pickcommit Use the specified commit as it is.
editcommit 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 gotadd
and gotremove commands can be used to add new files or remove existing
ones. The gotrevert-p command can be used to eliminate arbitrary
changes from files in the work tree. The gotstage-p command may be
used to prepare a subset of changes for inclusion in the next commit.
Finally, the gotcommit command can be used to insert arbitrary commits
into the edited history. Regular editing of history must eventually be
resumed by running gothistedit-c.
foldcommit Combine the specified commit with the next commit listed further below
that will be used.
dropcommit Remove this commit from the edited history.
mesgcommit 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 gothistedit-l command. Removal of these references makes objects which become unreachable via
any reference subject to removal by Git's garbage collector or gotadmincleanup.
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.
gothistedit 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 gotupdate. If changes have been staged with gotstage, these changes
must first be committed with gotcommit or unstaged with gotunstage. If the work tree
contains local changes, these changes must first be committed with gotcommit or reverted with
gotrevert. 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 gotupdate, gotrebase, gotmerge, and gotintegrate commands will refuse to run while a
histedit operation is in progress. Other commands which manipulate the work tree may be used,
and the gotcommit command may be used to commit arbitrary changes to the temporary branch
while the histedit operation is interrupted.
The options for gothistedit are as follows:
-a Abort an interrupted histedit operation. If this option is used, no other command-line
arguments are allowed.
-C Allow a histedit operation to continue with files in conflicted status. This option
should generally be avoided, and can only be used with the -c option.
-c Continue an interrupted histedit operation. If this option is used, no other command-
line arguments are allowed except -C.
-d Drop all commits. This option is a quick equivalent to a histedit script which drops
all commits. The -d option can only be used when starting a new histedit operation.
If this option is used, no other command-line arguments are allowed.
-e Interrupt the histedit operation for editing after merging each commit. This option is
a quick equivalent to a histedit script which uses the edit command for all commits.
The -e option can only be used when starting a new histedit operation. If this option
is used, no other command-line arguments are allowed.
-Fhistedit-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 gotlog command with the -c and -x options can be
used to examine the history of either version of the branch, and the gotbranch 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, gothistedit 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 gotadmincleanup.
If this option is used, gothistedit does not require a work tree. None of the other
options can be used together with -X.
integratebranch
(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 gotbranch-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
gotintegrate 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 gotrebase 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 gotupdate. If changes have been staged with gotstage, these changes must first be committed with
gotcommit or unstaged with gotunstage. If the work tree contains local changes, these
changes must first be committed with gotcommit or reverted with gotrevert.
merge [-aCcMn] [branch]
(alias: mg)
Merge the specified branch into the current branch of the work tree. If the branches have
diverged, merge changes into the work tree and create a merge commit. Otherwise, if the
specified branch is already based on the work tree's current branch, make the work tree's
current branch equivalent to the specified branch and update files in the work tree
accordingly.
Merge commits are commits 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 gotupdate-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 gotrebase should generally be preferred
over gotmerge. 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 gotimport.
While merging changes found on the branch into the work tree, show the status of each affected
file, using the following status codes:
U file was updated
G file was merged
C file was merged and conflicts occurred during merge
! changes destined for a missing file were not merged
D file was deleted
d file's deletion was prevented by local modifications
A new file was added
~ changes destined for a non-regular file were not merged
? changes destined for an unversioned file were not merged
If merge conflicts 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.
gotmerge 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 gotupdate-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 gotupdate. If the work tree contains multiple base commits, it must first be updated to
a single base commit with gotupdate. If changes have been staged with gotstage, these
changes must first be committed with gotcommit or unstaged with gotunstage. If the work tree
contains local changes, these changes must first be committed with gotcommit or reverted with
gotrevert. 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 gotupdate, gotcommit, gotrebase, gothistedit, gotintegrate, and gotstage 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 gotmerge 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 except -C.
-M Create a merge commit even if the branches have not diverged.
-n Merge changes into the work tree as usual but do not create a merge commit immediately.
The merge result can be adjusted as desired before a merge commit is created with gotmerge-c. Alternatively, the merge may be aborted with gotmerge-a.
stage [-lpS] [-Fresponse-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 gotstatus.
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 gotcommit, gotstatus, and gotdiff. While paths with
staged changes exist, the gotcommit 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 gotstatus command
will show both local changes and staged changes. The gotdiff command is able to display local
changes relative to staged changes, and to display staged changes relative to the repository.
The gotrevert command cannot revert staged changes but may be used to revert local changes
created on top of staged changes.
The options for gotstage are as follows:
-Fresponse-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, gotstage 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.
gotstage 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
gotupdate 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 gotupdate, gotrebase, gotmerge, and gothistedit 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 gotunstage before it can be updated with gotupdate, and
may then be staged again if necessary.
unstage [-p] [-Fresponse-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 gotunstage are as follows:
-Fresponse-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] [-ccommit] [-rrepository-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. References
will be resolved to an object ID. Tag names will resolved to a tag object. An abbreviated
hash argument will be expanded to a full commit ID automatically, provided the abbreviation is
unique.
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 gotcat are as follows:
-ccommit
Look up paths in the specified commit. If this option is not used, paths are looked up
in the commit resolved via the repository's HEAD reference.
The expected argument is a commit ID, or a reference name or keyword which will be
resolved to a commit ID. An abbreviated hash argument will be expanded to a full
commit ID automatically, provided the abbreviation is unique. The keywords ":base" and
":head" resolve to the work tree's base commit and branch head, respectively. The
former is only valid if invoked in a work tree, while the latter will resolve to the
tip of the work tree's current branch if invoked in a work tree, otherwise it will
resolve to the repository's HEAD reference. Keywords and references may be appended
with ":+" or ":-" modifiers and an optional integer N to denote the Nth descendant or
antecedent by first parent traversal, respectively; for example, :head:-2 denotes the
work tree branch head's 2nd generation ancestor, and :base:+4 denotes the 4th
generation descendant of the work tree's base commit. Similarly, quux:-8 will denote
the 8th generation ancestor of the commit resolved by the "quux" reference. A ":+" or
":-" modifier without a trailing integer has an implicit "1" appended (e.g., :base:+ is
equivalent to :base:+1).
-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.
-rrepository-path
Use the repository at the specified path. If not specified, assume the repository is
located at or above the current working directory. If this directory is a got work
tree, use the repository path associated with this work tree.
info [path...]
Display meta-data stored in a work tree. See got-worktree(5) for details.
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.
Install Now
PNG Icons
SVG Icons