NAME

got — Game of Trees

SYNOPSIS

DESCRIPTION

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

got is a “distributed” version control system because every copy of a repository is writeable. Modifications made to files can be synchronized between repositories at any time.

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

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

-h

Display usage information and exit immediately.

-V

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.

in

Short alias for init.

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

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

im

Short alias for import.

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

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

The options for got checkout are as follows:

-b branch

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

-c commit

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

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

co

Short alias for checkout.

update [-b branch] [-c commit] [path ...]

Update an existing work tree to a different commit. 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

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.

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

up

Short alias for update.

status [path ...]

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

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.

st

Short alias for status.

log [-c commit] [-C number] [-f] [-l N] [-p] [-r repository-path] [path]

Display history of a repository. If a path is specified, show only commits which modified this path.

The options for got log 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. 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.

-f

Restrict history traversal to the first parent of each commit. This shows the linear history of the current branch only. Merge commits which affected the current branch will be shown but individual commits which originated on other branches will be omitted.

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

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

diff [-C number] [-r repository-path] [-s] [-w] [object1 object2 | path]

When invoked within a work tree with less than two arguments, display uncommitted changes in the work tree. If a path is specified, only show changes within this path.

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.

The options for got diff are as follows:

-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. This option is only valid when got diff is invoked in a work tree.

-w

Ignore whitespace-only changes.

di

Short alias for diff.

blame [-c commit] [-r repository-path] path

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.

bl

Short alias for blame.

tree [-c commit] [-r repository-path] [-i] [-R] [path]

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

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.

tr

Short alias for tree.

ref [-r repository-path] [-l] [-d name] [-s] [name target]

Manage references in a repository.

If no options are passed, expect two arguments and attempt to create, or update, the reference with the given name, and make it point at the given target. The name must be an absolute reference name, i.e. it must begin with “refs/”. The target may be an object ID SHA1 hash or an existing reference which will be resolved to an object ID. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique.

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 all existing references in the repository.

-d name

Delete the reference with the specified name from the repository.

-s

Create a symbolic reference pointing at the specified target, which must be an existing reference. Care should be taken not to create loops between references when this option is used.

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

Manage branches in a repository.

Branches are managed via references which live in the “refs/heads/” reference namespace. The got branch command operates on references in this namespace only.

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.

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

-d name

Delete the branch with the specified name from the repository. 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.

br

Short alias for branch.

tag [-m message] [-r repository-path] [-l] name [commit]

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.

Expect one or two arguments and 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. Otherwise, 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.

The options for got tag are as follows:

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

Schedule unversioned files in a work tree for addition to the repository in the next commit.

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.

remove file-path ...

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

rm

Short alias for remove.

revert [-p] [-F response-script] [-R] path ...

Revert any uncommitted changes in files at the specified paths. 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.

rv

Short alias for revert.

commit [-m message] [path ...]

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.

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

-m message

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

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.

ci

Short alias for commit.

cherrypick commit

Merge changes from a single commit into the work tree. The specified commit must 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 obstructed by local modifications
A	new file was added
~	changes destined for a non-regular 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 the work tree already contains files with merge conflicts, these conflicts must be resolved first.

cy

Short alias for cherrypick.

backout commit

Reverse-merge changes from a single commit into the work tree. The specified commit must 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 obstructed by local modifications
A	new file was added
~	changes destined for a non-regular 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 the work tree already contains files with merge conflicts, these conflicts must be resolved first.

bo

Short alias for backout.

rebase [-a] [-c] [branch]

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.

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.

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 obstructed by local modifications
A	new file was added
~	changes destined for a non-regular file were not merged

If merge conflicts occur the rebase operation is interrupted and may be continued once conflicts have been resolved. 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 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 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.

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.

rb

Short alias for rebase.

histedit [-a] [-c] [-F histedit-script]

Edit commit history between the work tree's current base commit and the tip commit of the work tree's current branch.

Editing of commit history is controlled via a histedit script which can be edited interactively or passed on the command line. 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.

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.

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 obstructed by local modifications
A	new file was added
~	changes destined for a non-regular file were not merged

If merge conflicts occur the histedit operation is interrupted and may be continued once conflicts have been resolved. 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 command 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.

he

Short alias for histedit.

integrate branch

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.

ig

Short alias for integrate.

stage [-l] [-p] [-F response-script] [path ...]

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

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.

sg

Short alias for stage.

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

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

ug

Short alias for unstage.

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.

ENVIRONMENT

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.

If present, Git's user.name and user.email configuration settings in the repository's .git/config file will override the value of GOT_AUTHOR. However, the user.name and user.email configuration settings contained in Git's global ~/.gitconfig configuration file will be used only if the GOT_AUTHOR environment variable is not set.

VISUAL, EDITOR

The editor spawned by got commit, got import, or got tag.

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.

EXIT STATUS

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

EXAMPLES

Clone an existing Git repository for use with got. This step currently requires git(1):

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:

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

View local changes in a work tree directory:

Interactively revert selected local changes in a work tree directory:

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

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

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

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:

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:

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

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

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

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:

Fetch new upstream commits into the local repository's master branch. This step currently requires git(1):

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

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:

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

Additional steps are necessary if local changes need to be pushed back to the remote repository, which currently requires git fetch and git push. Before working against existing branches in a repository cloned with “git clone --bare”, 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 achieved by setting Git's remote.origin.fetch configuration variable to the value “+refs/heads/*:refs/remotes/origin/*” with the git config command:

Alternatively, the following fetch configuration item can be added manually to the Git repository's config file:

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 “remotes/origin” namespace can be updated with incoming changes from the remote repository with git fetch:

Before outgoing changes on the local “master” branch can be pushed to the remote repository, the local “master” branch must be rebased onto the “origin/master” branch:

Changes on the local “master” branch can then be pushed to the remote repository with git push:

In order to merge changes committed to the “unified-buffer-cache” branch back into the “master” branch, the “unified-buffer-cache” branch must first be rebased onto the “master” branch:

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 before the “unified-buffer-cache” branch can be integrated into “master”:

SEE ALSO

tog(1), git-repository(5), got-worktree(5)

AUTHORS

Stefan Sperling <stsp@openbsd.org>
Martin Pieuchot <mpi@openbsd.org>
Joshua Stein <jcs@openbsd.org>

CAVEATS

got is a work-in-progress and many commands remain to be implemented. At present, the user has to fall back on git(1) to perform many tasks, in particular tasks related to repository administration and tasks which require a network connection.