|
|
| |
GOT(1) |
FreeBSD General Commands Manual |
GOT(1) |
got |
command [-h ]
[arg ...] |
got is a version control system which stores the history
of tracked files in a Git repository, as used by the Git version control
system. This repository format is described in
git-repository(5).
got is a “distributed”
version control system because every copy of a repository is writeable.
Modifications made to files can be synchronized between repositories at any
time.
Files managed by got must be checked out
from the repository for modification. Checked out files are stored in a
work tree which can be placed at an arbitrary directory in
the filesystem hierarchy. The on-disk format of this work tree is described
in
got-worktree(5).
got provides global and command-specific
options. Global options must precede the command name, and are as
follows:
-h
- Display usage information and exit immediately.
-V ,
--version
- Display program version and exit immediately.
The commands for got are as follows:
init
repository-path
- Create a new empty repository at the specified
repository-path.
After got init , the
got import command must be used to populate the
empty repository before got checkout can be
used.
import
[-b branch]
[-m message]
[-r repository-path]
[-I pattern]
directory
-
(alias:
im )
Create an initial commit in a repository from the file hierarchy within the
specified directory. The created commit will not
have any parent commits, i.e. it will be a root commit. Also create a new
reference which provides a branch name for the newly created commit. Show
the path of each imported file to indicate progress.
The got import command requires the
GOT_AUTHOR environment variable to be set,
unless an author has been configured in
got.conf(5)
or Git's user.name and
user.email configuration settings can be
obtained from the repository's .git/config file
or from Git's global ~/.gitconfig configuration
file.
The options for got import are as
follows:
-b
branch
- Create the specified branch instead of creating
the default branch “main”. Use of this option is
required if the “main” branch already exists.
-m
message
- Use the specified log message when creating the new commit. Without
the
-m option, got
import opens a temporary file in an editor where a log message
can be written.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory.
-I
pattern
- Ignore files or directories with a name which matches the specified
pattern. This option may be specified multiple
times to build a list of ignore patterns. The
pattern follows the globbing rules documented in
glob(7).
clone
[-a ] [-b
branch] [-l ]
[-m ] [-q ]
[-v ] [-R
reference] repository-URL
[directory]
-
(alias:
cl )
Clone a Git repository at the specified repository-URL
into the specified directory. If no
directory is specified, the directory name will be
derived from the name of the cloned repository. got
clone will refuse to run if the directory
already exists.
The repository-URL specifies a protocol
scheme, a server hostname, an optional port number separated from the
hostname by a colon, and a path to the repository on the server:
scheme://hostname:port/path/to/repository
The following protocol schemes are supported:
- git
- The Git protocol as implemented by the
git-daemon(1)
server. Use of this protocol is discouraged since it supports neither
authentication nor encryption.
- git+ssh
- The Git protocol wrapped in an authenticated and encrypted
ssh(1)
tunnel. With this protocol the hostname may contain an embedded
username for
ssh(1)
to use:
user@hostname
- ssh
- Short alias for git+ssh.
Objects in the cloned repository are stored in a pack file
which is downloaded from the server. This pack file will then be indexed
to facilitate access to the objects stored within. If any objects in the
pack file are stored in deltified form, all deltas will be fully
resolved in order to compute the ID of such objects. This can take some
time. More details about the pack file format are documented in
git-repository(5).
got clone creates a remote repository
entry in the
got.conf(5)
and config files of the cloned repository to
store the repository-url and any
branch or reference
arguments for future use by got fetch or
git-fetch(1).
The options for got clone are as
follows:
-a
- Fetch all branches from the remote repository's
“refs/heads/” reference namespace and set
fetch-all-branches in the cloned repository's
got.conf(5)
file for future use by got fetch . If this
option is not specified, a branch resolved via the remote repository's
HEAD reference will be fetched. Cannot be used together with the
-b option.
-b
branch
- Fetch the specified branch from the remote
repository's “refs/heads/” reference namespace. This
option may be specified multiple times to build a list of branches to
fetch. If the branch corresponding to the remote repository's HEAD
reference is not in this list, the cloned repository's HEAD reference
will be set to the first branch which was fetched. If this option is
not specified, a branch resolved via the remote repository's HEAD
reference will be fetched. Cannot be used together with the
-a option.
-l
- List branches and tags available for fetching from the remote
repository and exit immediately. Cannot be used together with any of
the other options except
-q and
-v .
-m
- Create the cloned repository as a mirror of the original repository.
This is useful if the cloned repository will not be used to store
locally created commits.
The repository's
got.conf(5)
and config files will be set up with the
“mirror” option enabled, such that
got fetch or
git-fetch(1)
will write incoming changes directly to branches in the
“refs/heads/” reference namespace, rather than to
branches in the “refs/remotes/” namespace. This avoids
the usual requirement of having to run got
rebase after got fetch in order to
make incoming changes appear on branches in the
“refs/heads/” namespace. But maintaining custom
changes in the cloned repository becomes difficult since such
changes will be at risk of being discarded whenever incoming changes
are fetched.
-q
- Suppress progress reporting output. The same option will be passed to
ssh(1)
if applicable.
-v
- Verbose mode. Causes
got clone to print
debugging messages to standard error output. This option will be
passed to
ssh(1)
if applicable. Multiple -v options increase the verbosity. The maximum
is 3.
-R
reference
- In addition to the branches and tags that will be fetched, fetch an
arbitrary reference from the remote repository's
“refs/” namespace. This option may be specified multiple
times to build a list of additional references to fetch. The specified
reference may either be a path to a specific
reference, or a reference namespace which will cause all references in
this namespace to be fetched.
Each reference will be mapped into the cloned repository's
“refs/remotes/” namespace, unless the
-m option is used to mirror references
directly into the cloned repository's “refs/”
namespace.
got clone will refuse to fetch
references from the remote repository's
“refs/remotes/” or “refs/got/”
namespace.
fetch
[-a ] [-b
branch] [-d ]
[-l ] [-r
repository-path] [-t ]
[-q ] [-v ]
[-R reference]
[-X ] [remote-repository]
-
(alias:
fe )
Fetch new changes from a remote repository. If no
remote-repository is specified,
“origin” will be used. The remote repository's URL is
obtained from the corresponding entry in
got.conf(5)
or Git's config file of the local repository, as
created by got clone .
New changes will be stored in a separate pack file downloaded
from the server. Optionally, separate pack files stored in the
repository can be combined with
git-repack(1).
By default, branch references in the
“refs/remotes/” reference namespace will be updated to
point at the newly fetched commits. The got
rebase command can then be used to make new changes visible on
branches in the “refs/heads/” namespace, merging incoming
changes with the changes on those branches as necessary.
If the repository was created as a mirror with
got clone -m , then all branches in the
“refs/heads/” namespace will be updated directly to match
the corresponding branches in the remote repository. If those branches
contained local commits, these commits will no longer be reachable via a
reference and will therefore be at risk of being discarded by Git's
garbage collector or gotadmin cleanup .
Maintaining custom changes in a mirror repository is therefore
discouraged.
In any case, references in the “refs/tags/”
namespace will always be fetched and mapped directly to local references
in the same namespace.
The options for got fetch are as
follows:
-a
- Fetch all branches from the remote repository's
“refs/heads/” reference namespace. This option can be
enabled by default for specific repositories in
got.conf(5).
If this option is not specified, a branch resolved via the remote
repository's HEAD reference will be fetched. Cannot be used together
with the
-b option.
-b
branch
- Fetch the specified branch from the remote
repository's “refs/heads/” reference namespace. This
option may be specified multiple times to build a list of branches to
fetch. If 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.
-d
- Delete branches and tags from the local repository which are no longer
present in the remote repository. Only references are deleted. Any
commit, tree, tag, and blob objects belonging to deleted branches or
tags remain in the repository and may be removed separately with Git's
garbage collector or
gotadmin cleanup .
-l
- List branches and tags available for fetching from the remote
repository and exit immediately. Cannot be used together with any of
the other options except
-v ,
-q , and -r .
-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.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-q
- Suppress progress reporting output. The same option will be passed to
ssh(1)
if applicable.
-v
- Verbose mode. Causes
got fetch to print
debugging messages to standard error output. The same option will be
passed to
ssh(1)
if applicable. Multiple -v options increase the verbosity. The maximum
is 3.
-R
reference
- In addition to the branches and tags that will be fetched, fetch an
arbitrary reference from the remote repository's
“refs/” namespace. This option may be specified multiple
times to build a list of additional references to fetch. The specified
reference may either be a path to a specific
reference, or a reference namespace which will cause all references in
this namespace to be fetched.
Each reference will be mapped into the local repository's
“refs/remotes/” namespace, unless the local repository
was created as a mirror with got clone -m in
which case references will be mapped directly into the local
repository's “refs/” namespace.
Once a reference has been fetched, a branch based on it
can be created with got branch if
needed.
got fetch will refuse to fetch
references from the remote repository's
“refs/remotes/” or “refs/got/”
namespace.
-X
- Delete all references which correspond to a particular
remote-repository instead of fetching new
changes. This can be useful when a remote repository is being removed
from
got.conf(5).
With -X , the
remote-repository argument is mandatory and no
other options except -r ,
-v , and -q are
allowed.
Only references are deleted. Any commit, tree, tag, and
blob objects fetched from a remote repository will generally be
stored in pack files and may be removed separately with
git-repack(1)
and Git's garbage collector.
checkout
[-E ] [-b
branch] [-c
commit] [-p
path-prefix] [-q ]
repository-path
[work-tree-path]
-
(alias:
co )
Copy files from a repository into a new work tree. Show the status of each
affected file, using the following status codes:
A |
new file was added |
E |
file already exists in work tree's meta-data |
If the work tree path is not specified,
either use the last component of repository path,
or if a path prefix was specified use the last
component of path prefix.
The options for got checkout are as
follows:
-E
- Proceed with the checkout operation even if the directory at
work-tree-path is not empty. Existing files will
be left intact.
-b
branch
- Check out files from a commit on the specified
branch. If this option is not specified, a
branch resolved via the repository's HEAD reference will be used.
-c
commit
- Check out files from the specified commit on the
selected branch. The expected argument is a commit ID SHA1 hash or an
existing reference or tag name which will be resolved to a commit ID.
An abbreviated hash argument will be expanded to a full SHA1 hash
automatically, provided the abbreviation is unique. If this option is
not specified, the most recent commit on the selected branch will be
used.
If the specified commit is not
contained in the selected branch, a different branch which contains
this commit must be specified with the -b
option. If no such branch is known, a new branch must be created for
this commit with got branch before
got checkout can be used. Checking out work
trees with an unknown branch is intentionally not supported.
-p
path-prefix
- Restrict the work tree to a subset of the repository's tree hierarchy.
Only files beneath the specified path-prefix
will be checked out.
-q
- Silence progress output.
update
[-b branch]
[-c commit]
[-q ] [path ...]
-
(alias:
up )
Update an existing work tree to a different commit.
Change existing files in the work tree as necessary to match file contents
of this commit. Preserve any local changes in the work tree and merge them
with the incoming changes.
Files which already contain merge conflicts will not be
updated to avoid further complications. Such files will be updated when
got update is run again after merge conflicts
have been resolved. If the conflicting changes are no longer needed,
affected files can be reverted with got revert
before running got update again.
Show the status of each affected file, using the following
status codes:
U |
file was updated and contained no local changes |
G |
file was updated and local changes were merged cleanly |
C |
file was updated and conflicts occurred during merge |
D |
file was deleted |
A |
new file was added |
~ |
versioned file is obstructed by a non-regular file |
! |
a missing versioned file was restored |
# |
file was not updated because it contains merge conflicts |
? |
changes destined for an unversioned file were not merged |
If no path is specified, update the
entire work tree. Otherwise, restrict the update operation to files at
or within the specified paths. Each path is required to exist in the
update operation's target commit. Files in the work tree outside
specified paths will remain unchanged and will retain their previously
recorded base commit. Some got commands may
refuse to run while the work tree contains files from multiple base
commits. The base commit of such a work tree can be made consistent by
running got update across the entire work tree.
Specifying a path is incompatible with the
-b option.
got update cannot update paths with
staged changes. If changes have been staged with got
stage , these changes must first be committed with
got commit or unstaged with got
unstage .
The options for got update are as
follows:
-b
branch
- Switch the work tree's branch reference to the specified
branch before updating the work tree. This
option requires that all paths in the work tree are updated.
As usual, any local changes in the work tree will be
preserved. This can be useful when switching to a newly created
branch in order to commit existing local changes to this branch.
Any local changes must be dealt with separately in order
to obtain a work tree with pristine file contents corresponding
exactly to the specified branch. Such changes
could first be committed to a different branch with
got commit , or could be discarded with
got revert .
-c
commit
- Update the work tree to the specified commit.
The expected argument is a commit ID SHA1 hash or an existing
reference or tag name which will be resolved to a commit ID. An
abbreviated hash argument will be expanded to a full SHA1 hash
automatically, provided the abbreviation is unique. If this option is
not specified, the most recent commit on the work tree's branch will
be used.
-q
- Silence progress output.
status
[-I ] [-s
status-codes] [-S
status-codes] [path ...]
-
(alias:
st )
Show the current modification status of files in a work tree, using the
following status codes:
M |
modified file |
A |
file scheduled for addition in next commit |
D |
file scheduled for deletion in next commit |
C |
modified or added file which contains merge conflicts |
! |
versioned file was expected on disk but is missing |
~ |
versioned file is obstructed by a non-regular file |
? |
unversioned item not tracked by got |
m |
modified file modes (executable bit only) |
N |
non-existent path specified on the command
line |
If no path is specified, show
modifications in the entire work tree. Otherwise, show modifications at
or within the specified paths.
If changes have been staged with got
stage , staged changes are shown in the second output column,
using the following status codes:
M |
file modification is staged |
A |
file addition is staged |
D |
file deletion is staged |
Changes created on top of staged changes are indicated in the
first column:
MM |
file was modified after earlier changes have been staged |
MA |
file was modified after having been staged for addition |
The options for got status are as
follows:
-I
- Show unversioned files even if they match an ignore pattern.
-s
status-codes
- 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.
-S
status-codes
- Suppress the output of files with a modification status matching any
of the single-character status codes contained in the
status-codes argument. Any combination of codes
from the above list of possible status codes may be specified. For
staged files, status codes displayed in either column will be matched.
Cannot be used together with the
-s
option.
For compatibility with
cvs(1)
and
git(1),
got status reads
glob(7)
patterns from .cvsignore and
.gitignore files in each traversed directory and
will not display unversioned files which match these patterns. As an
extension to
glob(7)
matching rules, got status supports consecutive
asterisks, “**”, which will match an arbitrary amount of
directories. Unlike
cvs(1),
got status only supports a single ignore pattern
per line. Unlike
git(1),
got status does not support negated ignore
patterns prefixed with “!”, and gives no special
significance to the location of path component separators,
“/”, in a pattern.
log
[-b ] [-c
commit] [-C
number] [-l
N] [-p ]
[-P ] [-s
search-pattern] [-r
repository-path] [-R ]
[-x commit]
[path]
- Display history of a repository. If a path is
specified, show only commits which modified this path. If invoked in a
work tree, the path is interpreted relative to the
current working directory, and the work tree's path prefix is implicitly
prepended. Otherwise, the path is interpreted relative to the repository
root.
The options for got log are as
follows:
-b
- Display individual commits which were merged into the current branch
from other branches. By default,
got log shows
the linear history of the current branch only.
-c
commit
- Start traversing history at the specified
commit. The expected argument is a commit ID
SHA1 hash or an existing reference or tag name which will be resolved
to a commit ID. An abbreviated hash argument will be expanded to a
full SHA1 hash automatically, provided the abbreviation is unique. If
this option is not specified, default to the work tree's current
branch if invoked in a work tree, or to the repository's HEAD
reference.
-C
number
- Set the number of context lines shown in diffs with
-p . By default, 3 lines of context are
shown.
-l
N
- Limit history traversal to a given number of commits. If this option
is not specified, a default limit value of zero is used, which is
treated as an unbounded limit. The
GOT_LOG_DEFAULT_LIMIT environment variable may
be set to change this default value.
-p
- Display the patch of modifications made in each commit. If a
path is specified, only show the patch of
modifications at or within this path.
-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) |
-s
search-pattern
- If specified, show only commits with a log message matched by the
extended regular expression search-pattern. When
used together with
-P , then the file paths
changed by a commit can be matched as well. Regular expression syntax
is documented in
re_format(7).
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-R
- Determine a set of commits to display as usual, but display these
commits in reverse order.
-x
commit
- Stop traversing commit history immediately after the specified
commit has been traversed. This option has no
effect if the specified commit is never
traversed.
diff
[-a ] [-c
commit] [-C
number] [-r
repository-path] [-s ]
[-P ] [-w ]
[object1 object2 |
path ...]
-
(alias:
di )
When invoked within a work tree without any arguments, display all local
changes in the work tree. If one or more path
arguments are specified, only show changes within the specified paths.
If two arguments are provided, treat each argument as a
reference, a tag name, or an object ID SHA1 hash, and display
differences between the corresponding objects. Both objects must be of
the same type (blobs, trees, or commits). An abbreviated hash argument
will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique. If none of these interpretations produce a valid
result or if the -P option is used, and if
got diff is running in a work tree, attempt to
interpret the two arguments as paths.
The options for got diff are as
follows:
-a
- Treat file contents as ASCII text even if binary data is
detected.
-c
commit
- Show differences between commits in the repository. This options may
be used up to two times. When used only once, show differences between
the specified commit and its first parent
commit. When used twice, show differences between the two specified
commits.
The expected argument is a commit ID SHA1 hash or an
existing reference or tag name which will be resolved to a commit
ID. An abbreviated hash argument will be expanded to a full SHA1
hash automatically, provided the abbreviation is unique.
If the -c option is used, all
non-option arguments will be interpreted as paths. If one or more
such path arguments are provided, only show
differences for the specified paths.
Cannot be used together with the
-P option.
-C
number
- Set the number of context lines shown in the diff. By default, 3 lines
of context are shown.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-s
- Show changes staged with
got stage instead of
showing local changes in the work tree. This option is only valid when
got diff is invoked in a work tree.
-P
- Interpret all arguments as paths only. This option can be used to
resolve ambiguity in cases where paths look like tag names, reference
names, or object IDs. This option is only valid when
got diff is invoked in a work tree.
-w
- Ignore whitespace-only changes.
blame
[-c commit]
[-r repository-path]
path
-
(alias:
bl )
Display line-by-line history of a file at the specified path.
The options for got blame are as
follows:
-c
commit
- Start traversing history at the specified
commit. The expected argument is a commit ID
SHA1 hash or an existing reference or tag name which will be resolved
to a commit ID. An abbreviated hash argument will be expanded to a
full SHA1 hash automatically, provided the abbreviation is
unique.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
tree
[-c commit]
[-r repository-path]
[-i ] [-R ]
[path]
-
(alias:
tr )
Display a listing of files and directories at the specified directory path
in the repository. Entries shown in this listing may carry one of the
following trailing annotations:
@ |
entry is a symbolic link |
/ |
entry is a directory |
* |
entry is an executable file |
$ |
entry is a Git submodule |
Symbolic link entries are also annotated with the target path
of the link.
If no path is specified, list the
repository path corresponding to the current directory of the work tree,
or the root directory of the repository if there is no work tree.
The options for got tree are as
follows:
-c
commit
- List files and directories as they appear in the specified
commit. The expected argument is a commit ID
SHA1 hash or an existing reference or tag name which will be resolved
to a commit ID. An abbreviated hash argument will be expanded to a
full SHA1 hash automatically, provided the abbreviation is
unique.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-i
- Show object IDs of files (blob objects) and directories (tree
objects).
-R
- Recurse into sub-directories in the repository.
ref
[-r repository-path]
[-l ] [-t ]
[-c object]
[-s reference]
[-d ] [name]
- Manage references in a repository.
References may be listed, created, deleted, and changed. When
creating, deleting, or changing a reference the specified
name must be an absolute reference name, i.e. it
must begin with “refs/”.
The options for got ref are as
follows:
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-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 .
-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.
-c
object
- Create a reference or change an existing reference. The reference with
the specified name will point at the specified
object. The expected
object argument is a ID SHA1 hash or an existing
reference or tag name which will be resolved to the ID of a
corresponding commit, tree, tag, or blob object. Cannot be used
together with any other options except
-r .
-s
reference
- Create a symbolic reference, or change an existing symbolic reference.
The symbolic reference with the specified name
will point at the specified reference which must
already exist in the repository. Care should be taken not to create
loops between references when this option is used. Cannot be used
together with any other options except
-r .
-d
- Delete the reference with the specified name
from the repository. Any commit, tree, tag, and blob objects belonging
to deleted references remain in the repository and may be removed
separately with Git's garbage collector or
gotadmin
cleanup . Cannot be used together with any other options except
-r .
branch
[-c commit]
[-r repository-path]
[-l ] [-t ]
[-d name]
[-n ] [name]
-
(alias:
br )
Create, list, or delete branches.
Local branches are managed via references which live in the
“refs/heads/” reference namespace. The
got branch command creates references in this
namespace only.
When deleting branches, the specified
name is searched in the “refs/heads”
reference namespace first. If no corresponding branch is found, the
“refs/remotes” namespace will be searched next.
If invoked in a work tree without any arguments, print the
name of the work tree's current branch.
If a name argument is passed, attempt to
create a branch reference with the given name. By default the new branch
reference will point at the latest commit on the work tree's current
branch if invoked in a work tree, and otherwise to a commit resolved via
the repository's HEAD reference.
If invoked in a work tree, once the branch was created
successfully switch the work tree's head reference to the newly created
branch and update files across the entire work tree, just like
got update -b name would
do. Show the status of each affected file, using the following status
codes:
U |
file was updated and contained no local changes |
G |
file was updated and local changes were merged cleanly |
C |
file was updated and conflicts occurred during merge |
D |
file was deleted |
A |
new file was added |
~ |
versioned file is obstructed by a non-regular file |
! |
a missing versioned file was restored |
The options for got branch are as
follows:
-c
commit
- Make a newly created branch reference point at the specified
commit. The expected
commit argument is a commit ID SHA1 hash or an
existing reference or tag name which will be resolved to a commit
ID.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-l
- List all existing branches in the repository, including copies of
remote repositories' branches in the “refs/remotes/”
reference namespace.
If invoked in a work tree, the work tree's current branch
is shown with one the following annotations:
* |
work tree's base commit matches the branch tip |
~ |
work tree's base commit is out-of-date |
-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.
-d
name
- Delete the branch with the specified name from
the “refs/heads” or “refs/remotes”
reference namespace.
Only the branch reference is deleted. Any commit, tree,
and blob objects belonging to the branch remain in the repository
and may be removed separately with Git's garbage collector or
gotadmin cleanup .
-n
- Do not switch and update the work tree after creating a new
branch.
tag
[-c commit]
[-m message]
[-r repository-path]
[-l ] name
- Manage tags in a repository.
Tags are managed via references which live in the
“refs/tags/” reference namespace. The got
tag command operates on references in this namespace only.
References in this namespace point at tag objects which contain a
pointer to another object, a tag message, as well as author and
timestamp information.
Attempt to create a tag with the given
name, and make this tag point at the given
commit. If no commit is specified, default to the
latest commit on the work tree's current branch if invoked in a work
tree, and to a commit resolved via the repository's HEAD reference
otherwise.
The options for got tag are as
follows:
-c
commit
- Make the newly created tag reference point at the specified
commit. The expected
commit argument is a commit ID SHA1 hash or an
existing reference or tag name which will be resolved to a commit ID.
An abbreviated hash argument will be expanded to a full SHA1 hash
automatically, provided the abbreviation is unique.
-m
message
- Use the specified tag message when creating the new tag. Without the
-m option, got tag
opens a temporary file in an editor where a tag message can be
written.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-l
- List all existing tags in the repository instead of creating a new
tag. If this option is used, no other command-line arguments are
allowed.
By design, the got tag command will
not delete tags or change existing tags. If a tag must be deleted, the
got ref command may be used to delete a tag's
reference. This should only be done if the tag has not already been
copied to another repository.
add
[-R ] [-I ]
path ...
- Schedule unversioned files in a work tree for addition to the repository
in the next commit. By default, files which match a
got
status ignore pattern will not be added.
The options for got add are as
follows:
-R
- Permit recursion into directories. If this option is not specified,
got add will refuse to run if a specified
path is a directory.
-I
- Add files even if they match a
got status
ignore pattern.
remove
[-f ] [-k ]
[-R ] [-s
status-codes] path ...
-
(alias:
rm )
Remove versioned files from a work tree and schedule them for deletion from
the repository in the next commit.
The options for got remove are as
follows:
-f
- Perform the operation even if a file contains local modifications, and
do not raise an error if a specified path does
not exist on disk.
-k
- Keep affected files on disk.
-R
- Permit recursion into directories. If this option is not specified,
got remove will refuse to run if a specified
path is a directory.
-s
status-codes
- Only delete files with a modification status matching one of the
single-character status codes contained in the
status-codes argument. The following status
codes may be specified:
M |
modified file (this implies the -f
option) |
! |
versioned file expected on disk but missing |
patch
[-n ] [patchfile]
-
(alias:
pa )
Apply changes from patchfile to files in a work tree.
Files added or removed by a patch will be scheduled for addition or
removal in the work tree.
The patch must be in the unified diff format as produced by
got diff ,
git-diff(1),
or by
diff(1)
and
cvs(1)
diff when invoked with their -u options. If no
patchfile argument is provided, read unified diff
data from standard input instead.
If the patchfile contains multiple
patches, then attempt to apply each of them in sequence.
Show the status of each affected file, using the following
status codes:
M |
file was modified |
D |
file was deleted |
A |
file was added |
# |
failed to patch the file |
If a change does not match at its exact line number, attempt
to apply it somewhere else in the file if a good spot can be found.
Otherwise, the patch will fail to apply.
got patch will
refuse to apply a patch if certain preconditions are not met. Files to
be deleted must already be under version control, and must not have been
scheduled for deletion already. Files to be added must not yet be under
version control and must not already be present on disk. Files to be
modified must already be under version control and may not contain
conflict markers.
If an error occurs, the patch
operation will be aborted. Any changes made to the work tree up to this
point will be left behind. Such changes can be viewed with
got diff and can be reverted with
got revert if needed.
The options for got patch are as
follows:
-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.
revert
[-p ] [-F
response-script] [-R ]
path ...
-
(alias:
rv )
Revert any local changes in files at the specified paths in a work tree.
File contents will be overwritten with those contained in the work tree's
base commit. There is no way to bring discarded changes back after
got revert !
If a file was added with got add , it
will become an unversioned file again. If a file was deleted with
got remove , it will be restored.
The options for got revert are as
follows:
-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.
-F
response-script
- With the
-p option, read “y”,
“n”, and “q” responses line-by-line from
the specified response-script file instead of
prompting interactively.
-R
- Permit recursion into directories. If this option is not specified,
got revert will refuse to run if a specified
path is a directory.
commit
[-F path]
[-m message]
[-N ] [-S ]
[path ...]
-
(alias:
ci )
Create a new commit in the repository from changes in a work tree and use
this commit as the new base commit for the work tree. If no
path is specified, commit all changes in the work
tree. Otherwise, commit changes at or within the specified paths.
If changes have been explicitly staged for commit with
got stage , only commit staged changes and reject
any specified paths which have not been staged.
got commit opens a temporary file in
an editor where a log message can be written unless the
-m option is used or the
-F and -N options are
used together.
Show the status of each affected file, using the following
status codes:
M |
modified file |
D |
file was deleted |
A |
new file was added |
m |
modified file modes (executable bit only) |
Files which are not part of the new commit will retain their
previously recorded base commit. Some got
commands may refuse to run while the work tree contains files from
multiple base commits. The base commit of such a work tree can be made
consistent by running got update across the
entire work tree.
The got commit command requires the
GOT_AUTHOR environment variable to be set,
unless an author has been configured in
got.conf(5)
or Git's user.name and
user.email configuration settings can be
obtained from the repository's .git/config file
or from Git's global ~/.gitconfig configuration
file.
The options for got commit are as
follows:
-F
path
- Use the prepared log message stored in the file found at
path when creating the new commit.
got commit opens a temporary file in an editor
where the prepared log message can be reviewed and edited further if
needed. Cannot be used together with the -m
option.
-m
message
- Use the specified log message when creating the new commit. Cannot be
used together with the
-F option.
-N
- This option prevents
got commit from opening
the commit message in an editor. It has no effect unless it is used
together with the -F option and is intended
for non-interactive use such as scripting.
-S
- Allow the addition of symbolic links which point outside of the path
space that is under version control. By default,
got
commit will reject such symbolic links due to safety concerns.
As a precaution, got may decide to represent
such a symbolic link as a regular file which contains the link's
target path, rather than creating an actual symbolic link which points
outside of the work tree. Use of this option is discouraged because
external mechanisms such as “make obj” are better suited
for managing symbolic links to paths not under version control.
got commit will refuse to run if
certain preconditions are not met. If the work tree's current branch is
not in the “refs/heads/” reference namespace, new commits
may not be created on this branch. Local changes may only be committed
if they are based on file content found in the most recent commit on the
work tree's branch. If a path is found to be out of date,
got update must be used first in order to merge
local changes with changes made in the repository.
send
[-a ] [-b
branch] [-d
branch] [-f ]
[-r repository-path]
[-t tag]
[-T ] [-q ]
[-v ] [remote-repository]
-
(alias:
se )
Send new changes to a remote repository. If no
remote-repository is specified,
“origin” will be used. The remote repository's URL is
obtained from the corresponding entry in
got.conf(5)
or Git's config file of the local repository, as
created by got clone .
All objects corresponding to new changes will be written to a
temporary pack file which is then uploaded to the server. Upon success,
references in the “refs/remotes/” reference namespace of
the local repository will be updated to point at the commits which have
been sent.
By default, changes will only be sent if they are based on
up-to-date copies of relevant branches in the remote repository. If any
changes to be sent are based on out-of-date copies or would otherwise
break linear history of existing branches, new changes must be fetched
from the server with got fetch and local
branches must be rebased with got rebase before
got send can succeed. The
-f option can be used to make exceptions to
these requirements.
The options for got send are as
follows:
-a
- Send all branches from the local repository's
“refs/heads/” reference namespace. The
-a option is equivalent to listing all
branches with multiple -b options. Cannot be
used together with the -b option.
-b
branch
- Send the specified branch from the local
repository's “refs/heads/” reference namespace. This
option may be specified multiple times to build a list of branches to
send. If this option is not specified, default to the work tree's
current branch if invoked in a work tree, or to the repository's HEAD
reference. Cannot be used together with the
-a
option.
-d
branch
- Delete the specified branch from the remote
repository's “refs/heads/” reference namespace. This
option may be specified multiple times to build a list of branches to
delete.
Only references are deleted. Any commit, tree, tag, and
blob objects belonging to deleted branches may become subject to
deletion by Git's garbage collector running on the server.
Requesting deletion of branches results in an error if the
server does not support this feature or disallows the deletion of
branches based on its configuration.
-f
- Attempt to force the server to overwrite existing branches or tags in
the remote repository, even when
got fetch and
got rebase would usually be required before
changes can be sent. The server may reject forced requests regardless,
depending on its configuration.
Any commit, tree, tag, and blob objects belonging to
overwritten branches or tags may become subject to deletion by Git's
garbage collector running on the server.
The “refs/tags” reference namespace is
globally shared between all repositories. Use of the
-f option to overwrite tags is discouraged
because it can lead to inconsistencies between the tags present in
different repositories. In general, creating a new tag with a
different name is recommended instead of overwriting an existing
tag.
Use of the -f option is
particularly discouraged if changes being sent are based on an
out-of-date copy of a branch in the remote repository. Instead of
using the -f option, new changes should be
fetched with got fetch and local branches
should be rebased with got rebase , followed
by another attempt to send the changes.
The -f option should only be
needed in situations where the remote repository's copy of a branch
or tag is known to be out-of-date and is considered disposable. The
risks of creating inconsistencies between different repositories
should also be taken into account.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-t
tag
- Send the specified tag from the local
repository's “refs/tags/” reference namespace, in
addition to any branches that are being sent. The
-t option may be specified multiple times to
build a list of tags to send. No tags will be sent if the
-t option is not used.
Raise an error if the specified tag
already exists in the remote repository, unless the
-f option is used to overwrite the server's
copy of the tag. In general, creating a new tag with a different
name is recommended instead of overwriting an existing tag.
Cannot be used together with the
-T option.
-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.
-q
- Suppress progress reporting output. The same option will be passed to
ssh(1)
if applicable.
-v
- Verbose mode. Causes
got send to print
debugging messages to standard error output. The same option will be
passed to
ssh(1)
if applicable. Multiple -v options increase the verbosity. The maximum
is 3.
cherrypick
commit
-
(alias:
cy )
Merge changes from a single commit into the work tree.
The specified commit should be on a different branch
than the work tree's base commit. The expected argument is a reference or
a commit ID SHA1 hash. An abbreviated hash argument will be expanded to a
full SHA1 hash automatically, provided the abbreviation is unique.
Show the status of each affected file, using the following
status codes:
G |
file was merged |
C |
file was merged and conflicts occurred during merge |
! |
changes destined for a missing file were not merged |
D |
file was deleted |
d |
file's deletion was prevented by local modifications |
A |
new file was added |
~ |
changes destined for a non-regular file were not merged |
? |
changes destined for an unversioned file were not merged |
The merged changes will appear as local changes in the work
tree, which may be viewed with got diff , amended
manually or with further got cherrypick
commands, committed with got commit , or
discarded again with got revert .
got cherrypick will refuse to run if
certain preconditions are not met. If the work tree contains multiple
base commits, it must first be updated to a single base commit with
got update . If any relevant files already
contain merge conflicts, these conflicts must be resolved first.
backout
commit
-
(alias:
bo )
Reverse-merge changes from a single commit into the
work tree. The specified commit should be on the
same branch as the work tree's base commit. The expected argument is a
reference or a commit ID SHA1 hash. An abbreviated hash argument will be
expanded to a full SHA1 hash automatically, provided the abbreviation is
unique.
Show the status of each affected file, using the following
status codes:
G |
file was merged |
C |
file was merged and conflicts occurred during merge |
! |
changes destined for a missing file were not merged |
D |
file was deleted |
d |
file's deletion was prevented by local modifications |
A |
new file was added |
~ |
changes destined for a non-regular file were not merged |
? |
changes destined for an unversioned file were not merged |
The reverse-merged changes will appear as local changes in the
work tree, which may be viewed with got diff ,
amended manually or with further got backout
commands, committed with got commit , or
discarded again with got revert .
got backout will refuse to run if
certain preconditions are not met. If the work tree contains multiple
base commits, it must first be updated to a single base commit with
got update . If any relevant files already
contain merge conflicts, these conflicts must be resolved first.
rebase
[-a ] [-c ]
[-l ] [-X ]
[branch]
-
(alias:
rb )
Rebase commits on the specified branch onto the tip of
the current branch of the work tree. The branch must
share common ancestry with the work tree's current branch. Rebasing begins
with the first descendant commit of the youngest common ancestor commit
shared by the specified branch and the work tree's
current branch, and stops once the tip commit of the specified
branch has been rebased.
When got rebase is used as intended,
the specified branch represents a local commit
history and may already contain changes that are not yet visible in any
other repositories. The work tree's current branch, which must be set
with got update -b before starting the
rebase operation, represents a branch from a
remote repository which shares a common history with the specified
branch but has progressed, and perhaps diverged,
due to commits added to the remote repository.
Rebased commits are accumulated on a temporary branch which
the work tree will remain switched to throughout the entire rebase
operation. Commits on this branch represent the same changes with the
same log messages as their counterparts on the original
branch, but with different commit IDs. Once
rebasing has completed successfully, the temporary branch becomes the
new version of the specified branch and the work
tree is automatically switched to it.
Old commits in their pre-rebase state are automatically backed
up in the “refs/got/backup/rebase” reference namespace. As
long as these references are not removed older versions of rebased
commits will remain in the repository and can be viewed with the
got rebase -l command. Removal of these
references makes objects which become unreachable via any reference
subject to removal by Git's garbage collector or
gotadmin cleanup .
While rebasing commits, show the status of each affected file,
using the following status codes:
G |
file was merged |
C |
file was merged and conflicts occurred during merge |
! |
changes destined for a missing file were not merged |
D |
file was deleted |
d |
file's deletion was prevented by local modifications |
A |
new file was added |
~ |
changes destined for a non-regular file were not merged |
? |
changes destined for an unversioned file were not merged |
If merge conflicts occur, the rebase operation is interrupted
and may be continued once conflicts have been resolved. If any files
with destined changes are found to be missing or unversioned, or if
files could not be deleted due to differences in deleted content, the
rebase operation will be interrupted to prevent potentially incomplete
changes from being committed to the repository without user
intervention. The work tree may be modified as desired and the rebase
operation can be continued once the changes present in the work tree are
considered complete. Alternatively, the rebase operation may be aborted
which will leave branch unmodified and the work
tree switched back to its original branch.
If a merge conflict is resolved in a way which renders the
merged change into a no-op change, the corresponding commit will be
elided when the rebase operation continues.
got rebase will refuse to run if
certain preconditions are not met. If the work tree is not yet fully
updated to the tip commit of its branch, then the work tree must first
be updated with got update . If changes have been
staged with got stage , these changes must first
be committed with got commit or unstaged with
got unstage . If the work tree contains local
changes, these changes must first be committed with got
commit or reverted with got revert . If
the branch contains changes to files outside of
the work tree's path prefix, the work tree cannot be used to rebase this
branch.
The got update and
got commit commands will refuse to run while a
rebase operation is in progress. Other commands which manipulate the
work tree may be used for conflict resolution purposes.
If the specified branch is already based
on the work tree's current branch, then no commits need to be rebased
and got rebase will simply switch the work tree
to the specified branch and update files in the
work tree accordingly.
The options for got rebase are as
follows:
-a
- Abort an interrupted rebase operation. If this option is used, no
other command-line arguments are allowed.
-c
- Continue an interrupted rebase operation. If this option is used, no
other command-line arguments are allowed.
-l
- Show a list of past rebase operations, represented by references in
the “refs/got/backup/rebase” reference namespace.
Display the author, date, and log message of each backed
up commit, the object ID of the corresponding post-rebase commit,
and the object ID of their common ancestor commit. Given these
object IDs, the got log command with the
-c and -x options
can be used to examine the history of either version of the branch,
and the got branch command with the
-c option can be used to create a new branch
from a pre-rebase state if desired.
If a branch is specified, only show
commits which at some point in time represented this branch.
Otherwise, list all backed up commits for any branches.
If this option is used, got rebase
does not require a work tree. None of the other options can be used
together with -l .
-X
- Delete backups created by past rebase operations, represented by
references in the “refs/got/backup/rebase” reference
namespace.
If a branch is specified, only
delete backups which at some point in time represented this branch.
Otherwise, delete all references found within
“refs/got/backup/rebase”.
Any commit, tree, tag, and blob objects belonging to
deleted backups remain in the repository and may be removed
separately with Git's garbage collector or gotadmin
cleanup .
If this option is used, got rebase
does not require a work tree. None of the other options can be used
together with -X .
histedit
[-a ] [-c ]
[-e ] [-f ]
[-F histedit-script]
[-m ] [-l ]
[-X ] [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.
Before starting a histedit operation,
the work tree's current branch must be set with got
update -b to the branch which should be edited, unless this
branch is already the current branch of the work tree. The tip of this
branch represents the upper bound (inclusive) of commits touched by the
histedit operation.
Furthermore, the work tree's base commit must be set with
got update -c to a point in this branch's commit
history where editing should begin. This commit represents the lower
bound (non-inclusive) of commits touched by the
histedit operation.
Editing of commit history is controlled via a
histedit script which can be written in an editor
based on a template, passed on the command line, or generated with the
-f or -m options.
The format of the histedit script is line-based. Each line in
the script begins with a command name, followed by whitespace and an
argument. For most commands, the expected argument is a commit ID SHA1
hash. Any remaining text on the line is ignored. Lines which begin with
the ‘#’ character are ignored entirely.
The available commands are as follows:
pick commit |
Use the specified commit as it is. |
edit commit |
Use the specified commit but once changes have been merged into the
work tree interrupt the histedit operation for amending. |
fold commit |
Combine the specified commit with the next commit listed further
below that will be used. |
drop commit |
Remove this commit from the edited history. |
mesg log-message |
Use the specified single-line log message for the commit on the
previous line. If the log message argument is left empty, open an
editor where a new log message can be written. |
Every commit in the history being edited must be mentioned in
the script. Lines may be re-ordered to change the order of commits in
the edited history. No commit may be listed more than once.
Edited commits are accumulated on a temporary branch which the
work tree will remain switched to throughout the entire histedit
operation. Once history editing has completed successfully, the
temporary branch becomes the new version of the work tree's branch and
the work tree is automatically switched to it.
Old commits in their pre-histedit state are automatically
backed up in the “refs/got/backup/histedit” reference
namespace. As long as these references are not removed older versions of
edited commits will remain in the repository and can be viewed with the
got histedit -l command. Removal of these
references makes objects which become unreachable via any reference
subject to removal by Git's garbage collector or
gotadmin cleanup .
While merging commits, show the status of each affected file,
using the following status codes:
G |
file was merged |
C |
file was merged and conflicts occurred during merge |
! |
changes destined for a missing file were not merged |
D |
file was deleted |
d |
file's deletion was prevented by local modifications |
A |
new file was added |
~ |
changes destined for a non-regular file were not merged |
? |
changes destined for an unversioned file were not merged |
If merge conflicts occur, the histedit operation is
interrupted and may be continued once conflicts have been resolved. If
any files with destined changes are found to be missing or unversioned,
or if files could not be deleted due to differences in deleted content,
the histedit operation will be interrupted to prevent potentially
incomplete changes from being committed to the repository without user
intervention. The work tree may be modified as desired and the histedit
operation can be continued once the changes present in the work tree are
considered complete. Alternatively, the histedit operation may be
aborted which will leave the work tree switched back to its original
branch.
If a merge conflict is resolved in a way which renders the
merged change into a no-op change, the corresponding commit will be
elided when the histedit operation continues.
got histedit will refuse to run if
certain preconditions are not met. If the work tree's current branch is
not in the “refs/heads/” reference namespace, the history
of the branch may not be edited. If the work tree contains multiple base
commits, it must first be updated to a single base commit with
got update . If changes have been staged with
got stage , these changes must first be committed
with got commit or unstaged with
got unstage . If the work tree contains local
changes, these changes must first be committed with got
commit or reverted with got revert . If
the edited history contains changes to files outside of the work tree's
path prefix, the work tree cannot be used to edit the history of this
branch.
The got update , got
rebase , and got integrate commands will
refuse to run while a histedit operation is in progress. Other commands
which manipulate the work tree may be used, and the got
commit command may be used to commit arbitrary changes to the
temporary branch while the histedit operation is interrupted.
The options for got histedit are as
follows:
-a
- Abort an interrupted histedit operation. If this option is used, no
other command-line arguments are allowed.
-c
- Continue an interrupted histedit operation. If this option is used, no
other command-line arguments are allowed.
-e
- Interrupt the histedit operation for editing after merging each
commit. This option is a quick equivalent to a histedit script which
uses the
edit command for all commits. The
-e option can only be used when starting a new
histedit operation. If this option is used, no other command-line
arguments are allowed.
-f
- 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.
-F
histedit-script
- Use the specified histedit-script instead of
opening a temporary file in an editor where a histedit script can be
written.
-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.
-l
- Show a list of past histedit operations, represented by references in
the “refs/got/backup/histedit” reference namespace.
Display the author, date, and log message of each backed
up commit, the object ID of the corresponding post-histedit commit,
and the object ID of their common ancestor commit. Given these
object IDs, the got log command with the
-c and -x options
can be used to examine the history of either version of the branch,
and the got branch command with the
-c option can be used to create a new branch
from a pre-histedit state if desired.
If a branch is specified, only show
commits which at some point in time represented this branch.
Otherwise, list all backed up commits for any branches.
If this option is used, got
histedit does not require a work tree. None of the other
options can be used together with -l .
-X
- Delete backups created by past histedit operations, represented by
references in the “refs/got/backup/histedit” reference
namespace.
If a branch is specified, only
delete backups which at some point in time represented this branch.
Otherwise, delete all references found within
“refs/got/backup/histedit”.
Any commit, tree, tag, and blob objects belonging to
deleted backups remain in the repository and may be removed
separately with Git's garbage collector or gotadmin
cleanup .
If this option is used, got
histedit does not require a work tree. None of the other
options can be used together with -X .
integrate
branch
-
(alias:
ig )
Integrate the specified branch into the work tree's
current branch. Files in the work tree are updated to match the contents
on the integrated branch, and the reference of the
work tree's branch is changed to point at the head commit of the
integrated branch.
Both branches can be considered equivalent after integration
since they will be pointing at the same commit. Both branches remain
available for future work, if desired. In case the integrated
branch is no longer needed it may be deleted with
got branch -d .
Show the status of each affected file, using the following
status codes:
U |
file was updated |
D |
file was deleted |
A |
new file was added |
~ |
versioned file is obstructed by a non-regular file |
! |
a missing versioned file was restored |
got integrate will refuse to run if
certain preconditions are not met. Most importantly, the
branch must have been rebased onto the work tree's
current branch with got rebase before it can be
integrated, in order to linearize commit history and resolve merge
conflicts. If the work tree contains multiple base commits, it must
first be updated to a single base commit with got
update . If changes have been staged with got
stage , these changes must first be committed with
got commit or unstaged with got
unstage . If the work tree contains local changes, these changes
must first be committed with got commit or
reverted with got revert .
merge
[-a ] [-c ]
[-n ] [branch]
-
(alias:
mg )
Create a merge commit based on the current branch of the work tree and the
specified branch. If a linear project history is
desired, then use of got rebase should be
preferred over got merge . However, even strictly
linear projects may require merge commits in order to merge in new
versions of third-party code stored on vendor branches created with
got import .
Merge commits are commits based on multiple parent commits.
The tip commit of the work tree's current branch, which must be set with
got update -b before starting the
merge operation, will be used as the first
parent. The tip commit of the specified branch
will be used as the second parent.
No ancestral relationship between the two branches is
required. If the two branches have already been merged previously, only
new changes will be merged.
It is not possible to create merge commits with more than two
parents. If more than one branch needs to be merged, then multiple merge
commits with two parents each can be created in sequence.
While merging changes found on the
branch into the work tree, show the status of each
affected file, using the following status codes:
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.
If a merge conflict is resolved in a way which renders all
merged changes into no-op changes, the merge operation cannot continue
and must be aborted.
got merge will refuse to run if
certain preconditions are not met. If history of the
branch is based on the work tree's current branch,
then no merge commit can be created and got
integrate may be used to integrate the
branch instead. If the work tree is not yet fully
updated to the tip commit of its branch, then the work tree must first
be updated with got update . If the work tree
contains multiple base commits, it must first be updated to a single
base commit with got update . If changes have
been staged with got stage , these changes must
first be committed with got commit or unstaged
with got unstage . If the work tree contains
local changes, these changes must first be committed with
got commit or reverted with got
revert . If the branch contains changes to
files outside of the work tree's path prefix, the work tree cannot be
used to merge this branch.
The got update , got
commit , got rebase , got
histedit , got integrate , and
got stage commands will refuse to run while a
merge operation is in progress. Other commands which manipulate the work
tree may be used for conflict resolution purposes.
The options for got merge are as
follows:
-a
- Abort an interrupted merge operation. If this option is used, no other
command-line arguments are allowed.
-c
- Continue an interrupted merge operation. If this option is used, no
other command-line arguments are allowed.
-n
- Merge changes into the work tree as usual but do not create a merge
commit immediately. The merge result can be adjusted as desired before
a merge commit is created with
got merge -c .
Alternatively, the merge may be aborted with got
merge -a .
stage
[-l ] [-p ]
[-F response-script]
[-S ] [path ...]
-
(alias:
sg )
Stage local changes for inclusion in the next commit. If no
path is specified, stage all changes in the work
tree. Otherwise, stage changes at or within the specified paths. Paths may
be staged if they are added, modified, or deleted according to
got status .
Show the status of each affected file, using the following
status codes:
A |
file addition has been staged |
M |
file modification has been staged |
D |
file deletion has been staged |
Staged file contents are saved in newly created blob objects
in the repository. These blobs will be referred to by tree objects once
staged changes have been committed.
Staged changes affect the behaviour of got
commit , got status , and
got diff . While paths with staged changes exist,
the got commit command will refuse to commit any
paths which do not have staged changes. Local changes created on top of
staged changes can only be committed if the path is staged again, or if
the staged changes are committed first. The got
status command will show both local changes and staged changes.
The got diff command is able to display local
changes relative to staged changes, and to display staged changes
relative to the repository. The got revert
command cannot revert staged changes but may be used to revert local
changes created on top of staged changes.
The options for got stage are as
follows:
-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.
-F
response-script
- With the
-p option, read “y”,
“n”, and “q” responses line-by-line from
the specified response-script file instead of
prompting interactively.
-S
- Allow staging of symbolic links which point outside of the path space
that is under version control. By default,
got
stage will reject such symbolic links due to safety concerns.
As a precaution, got may decide to represent
such a symbolic link as a regular file which contains the link's
target path, rather than creating an actual symbolic link which points
outside of the work tree. Use of this option is discouraged because
external mechanisms such as “make obj” are better suited
for managing symbolic links to paths not under version control.
got stage will refuse to run if
certain preconditions are not met. If a file contains merge conflicts,
these conflicts must be resolved first. If a file is found to be out of
date relative to the head commit on the work tree's current branch, the
file must be updated with got update before it
can be staged (however, this does not prevent the file from becoming
out-of-date at some point after having been staged).
The got update , got
rebase , and got histedit commands will
refuse to run while staged changes exist. If staged changes cannot be
committed because a staged path is out of date, the path must be
unstaged with got unstage before it can be
updated with got update , and may then be staged
again if necessary.
unstage
[-p ] [-F
response-script] [path ...]
-
(alias:
ug )
Merge staged changes back into the work tree and put affected paths back
into non-staged status. If no path is specified,
unstage all staged changes across the entire work tree. Otherwise, unstage
changes at or within the specified paths.
Show the status of each affected file, using the following
status codes:
G |
file was unstaged |
C |
file was unstaged and conflicts occurred during merge |
! |
changes destined for a missing file were not merged |
D |
file was staged as deleted and still is deleted |
d |
file's deletion was prevented by local modifications |
~ |
changes destined for a non-regular file were not merged |
The options for got unstage are as
follows:
-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.
-F
response-script
- With the
-p option, read “y”,
“n”, and “q” responses line-by-line from
the specified response-script file instead of
prompting interactively.
cat
[-c commit]
[-r repository-path]
[-P ] arg ...
- Parse and print contents of objects to standard output in a line-based
text format. Content of commit, tree, and tag objects is printed in a way
similar to the actual content stored in such objects. Blob object contents
are printed as they would appear in files on disk.
Attempt to interpret each argument as a reference, a tag name,
or an object ID SHA1 hash. References will be resolved to an object ID.
Tag names will resolved to a tag object. An abbreviated hash argument
will be expanded to a full SHA1 hash automatically, provided the
abbreviation is unique.
If none of the above interpretations produce a valid result,
or if the -P option is used, attempt to
interpret the argument as a path which will be resolved to the ID of an
object found at this path in the repository.
The options for got cat are as
follows:
-c
commit
- Look up paths in the specified commit. If this
option is not used, paths are looked up in the commit resolved via the
repository's HEAD reference. The expected argument is a commit ID SHA1
hash or an existing reference or tag name which will be resolved to a
commit ID. An abbreviated hash argument will be expanded to a full
SHA1 hash automatically, provided the abbreviation is unique.
-r
repository-path
- Use the repository at the specified path. If not specified, assume the
repository is located at or above the current working directory. If
this directory is a
got work tree, use the
repository path associated with this work tree.
-P
- Interpret all arguments as paths only. This option can be used to
resolve ambiguity in cases where paths look like tag names, reference
names, or object IDs.
info
[path ...]
- Display meta-data stored in a work tree. See
got-worktree(5)
for details.
The work tree to use is resolved implicitly by walking upwards
from the current working directory.
If one or more path arguments are
specified, show additional per-file information for tracked files
located at or within these paths. If a path
argument corresponds to the work tree's root directory, display
information for all tracked files.
GOT_AUTHOR
- The author's name and email address for
got commit
and got import , for example:
“Flan Hacker
<flan_hacker@openbsd.org>”.
Because
git(1)
may fail to parse commits without an email address in author data,
got attempts to reject
GOT_AUTHOR environment variables with a missing
email address.
GOT_AUTHOR will be overridden by
configuration settings in
got.conf(5)
or by Git's user.name and
user.email configuration settings in the
repository's .git/config file. The
user.name and user.email
configuration settings contained in Git's global
~/.gitconfig configuration file will only be
used if neither
got.conf(5)
nor the GOT_AUTHOR environment variable provide
author information.
VISUAL ,
EDITOR
- The editor spawned by
got commit ,
got histedit , got import ,
or got tag . If not set, the
ed(1)
text editor will be spawned in order to give
ed(1) the
attention it deserves.
GOT_LOG_DEFAULT_LIMIT
- The default limit on the number of commits traversed by
got log . If set to zero, the limit is unbounded.
This variable will be silently ignored if it is set to a non-numeric
value.
- got.conf
- Repository-wide configuration settings for
got . If
present, a
got.conf(5)
configuration file located in the root directory of a Git repository
supersedes any relevant settings in Git's config
file.
- .got/got.conf
- Worktree-specific configuration settings for
got .
If present, a
got.conf(5)
configuration file in the .got meta-data directory
of a work tree supersedes any relevant settings in the repository's
got.conf(5)
configuration file and Git's config file.
The got utility exits 0 on success,
and >0 if an error occurs.
Enable tab-completion of got command names in
ksh(1):
$ set -A complete_got_1 -- $(got -h
2>&1 | sed -n s/commands://p)
Clone an existing Git repository for use with
got .
$ cd /var/git/
$ got clone
ssh://git@github.com/openbsd/src.git
Use of HTTP URLs currently requires
git(1):
$ cd /var/git/
$ git clone --bare
https://github.com/openbsd/src.git
Alternatively, for quick and dirty local testing of
got a new Git repository could be created and
populated with files, e.g. from a temporary CVS checkout located at
/tmp/src:
$ got init
/var/git/src.git
$ got import -r /var/git/src.git -I
CVS -I obj /tmp/src
Check out a work tree from the Git repository to /usr/src:
$ got checkout /var/git/src.git
/usr/src
View local changes in a work tree directory:
$ got diff | less
In a work tree, display files in a potentially problematic
state:
$ got status -s 'C!~?'
Interactively revert selected local changes in a work tree
directory:
$ got revert -p
-R .
In a work tree or a git repository directory, list all branch
references:
$ got branch -l
In a work tree or a git repository directory, create a new branch
called “unified-buffer-cache” which is forked off the
“master” branch:
$ got branch -c master
unified-buffer-cache
Switch an existing work tree to the branch
“unified-buffer-cache”. Local changes in the work tree will be
preserved and merged if necessary:
$ got update -b
unified-buffer-cache
Create a new commit from local changes in a work tree directory.
This new commit will become the head commit of the work tree's current
branch:
$ got commit
In a work tree or a git repository directory, view changes
committed in the 3 most recent commits to the work tree's branch, or the
branch resolved via the repository's HEAD reference, respectively:
$ got log -p -l 3
As above, but display changes in the order in which
patch(1)
could apply them in sequence:
$ got log -p -l 3 -R
In a work tree or a git repository directory, log the history of a
subdirectory:
$ got log sys/uvm
While operating inside a work tree, paths are specified relative
to the current working directory, so this command will log the subdirectory
sys/uvm:
$ cd sys/uvm && got
log .
And this command has the same effect:
$ cd sys/dev/usb && got log
../../uvm
And this command displays work tree meta-data about all tracked
files:
$ cd /usr/src
$ got info . |
less
Add new files and remove obsolete files in a work tree
directory:
$ got add
sys/uvm/uvm_ubc.c
$ got remove
sys/uvm/uvm_vnode.c
Create a new commit from local changes in a work tree directory
with a pre-defined log message.
$ got commit -m 'unify the buffer
cache'
Alternatively, create a new commit from local changes in a work
tree directory with a log message that has been prepared in the file
/tmp/msg:
$ got commit -F /tmp/msg
Update any work tree checked out from the
“unified-buffer-cache” branch to the latest commit on this
branch:
$ got update
Roll file content on the unified-buffer-cache branch back by one
commit, and then fetch the rolled-back change into the work tree as a local
change to be amended and perhaps committed again:
$ got backout
unified-buffer-cache
$ got commit -m 'roll back
previous'
$ # now back out the previous backout
:-)
$ got backout
unified-buffer-cache
Fetch new changes on the remote repository's
“master” branch, making them visible on the local repository's
“origin/master” branch:
$ cd /usr/src
$ got fetch
In a repository created with a HTTP URL and git
clone --bare the
git-fetch(1)
command must be used instead:
$ cd /var/git/src.git
$ git fetch origin
master:refs/remotes/origin/master
Rebase the local “master” branch to merge the new
changes that are now visible on the “origin/master”
branch:
$ cd /usr/src
$ got update -b
origin/master
$ got rebase master
Rebase the “unified-buffer-cache” branch on top of
the new head commit of the “master” branch.
$ got update -b master
$ got rebase
unified-buffer-cache
Create a patch from all changes on the unified-buffer-cache
branch. The patch can be mailed out for review and applied to
OpenBSD's CVS tree:
$ got diff master
unified-buffer-cache > /tmp/ubc.diff
Edit the entire commit history of the
“unified-buffer-cache” branch:
$ got update -b
unified-buffer-cache
$ got update -c master
$ got histedit
Before working against existing branches in a repository cloned
with git clone --bare instead of
got clone , a Git “refspec” must be
configured to map all references in the remote repository into the
“refs/remotes” namespace of the local repository. This can be
achieved by setting Git's remote.origin.fetch
configuration variable to the value
“+refs/heads/*:refs/remotes/origin/*” with the
git config command:
$ cd /var/git/repo
$ git config remote.origin.fetch
'+refs/heads/*:refs/remotes/origin/*'
Additionally, the “mirror” option must be
disabled:
$ cd /var/git/repo
$ git config remote.origin.mirror
false
Alternatively, the following
git-fetch(1)
configuration item can be added manually to the Git repository's
config file:
[remote
"origin"]
url = ...
fetch =
+refs/heads/*:refs/remotes/origin/*
mirror = false
This configuration leaves the local repository's
“refs/heads” namespace free for use by local branches checked
out with got checkout and, if needed, created with
got branch . Branches in the
“refs/remotes/origin” namespace can now be updated with
incoming changes from the remote repository with got
fetch or
git-fetch(1)
without extra command line arguments. Newly fetched changes can be examined
with got log .
Display changes on the remote repository's version of the
“master” branch, as of the last time got
fetch was run:
$ got log -c origin/master |
less
As shown here, most commands accept abbreviated reference names
such as “origin/master” instead of
“refs/remotes/origin/master”. The latter is only needed in
case of ambiguity.
got rebase must be used to merge changes
which are visible on the “origin/master” branch into the
“master” branch. This will also merge local changes, if any,
with the incoming changes:
$ got update -b
origin/master
$ got rebase master
In order to make changes committed to the
“unified-buffer-cache” visible on the “master”
branch, the “unified-buffer-cache” branch must first be
rebased onto the “master” branch:
$ got update -b master
$ got rebase
unified-buffer-cache
Changes on the “unified-buffer-cache” branch can now
be made visible on the “master” branch with
got integrate . Because the rebase operation switched
the work tree to the “unified-buffer-cache” branch, the work
tree must be switched back to the “master” branch first:
$ got update -b master
$ got integrate
unified-buffer-cache
On the “master” branch, log messages for local
changes can now be amended with “OK” by other developers and
any other important new information:
$ got update -c
origin/master
$ got histedit -m
If the remote repository offers write access, local changes on the
“master” branch can be sent to the remote repository with
got send . Usually, got send
can be run without further arguments. The arguments shown here match
defaults, provided the work tree's current branch is the
“master” branch:
$ got send -b master
origin
If the remote repository requires the HTTPS protocol, the
git-push(1)
command must be used instead:
$ cd /var/git/src.git
$ git push origin master
got is a work-in-progress and some features remain to be
implemented.
At present, the user has to fall back on
git(1) to
perform some tasks. In particular:
- Reading from remote repositories over HTTP or HTTPS protocols requires
git-clone(1)
and
git-fetch(1).
- Writing to remote repositories over HTTP or HTTPS protocols requires
git-push(1).
- The creation of merge commits with more than two parent commits requires
git-merge(1).
- In situations where files or directories were moved around
got will not automatically merge changes to new
locations and
git(1)
will usually produce better results.
Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc. |