NAME¶

cvg — CVS-like Git client

SYNOPSIS¶

DESCRIPTION¶

cvg is a Git-compatible version control system with a user interface similar to cvs(1).

cvg supports local and remote Git repositories. The Git repository format is described in git-repository(5).

Files managed by cvg 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 cvg-worktree(5).

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

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

(alias: im)

Create an initial commit in a repository from the file hierarchy within the specified directory. The created commit will not have any parent commits, i.e. it will be a root commit. Also create a new reference which provides a branch name for the newly created commit. Show the path of each imported file to indicate progress.

The got import command requires the GOT_AUTHOR environment variable to be set, unless an author has been configured in got.conf(5) or Git's user.name and user.email configuration settings can be obtained from the repository's .git/config file or from Git's global ~/.gitconfig configuration file.

The options for got import are as follows:

-b branch

Create the specified branch. If this option is not specified, a branch corresponding to the repository's HEAD reference will be used. Use of this option is required if the branch resolved via the repository's HEAD reference already exists.

-I pattern

Ignore files or directories with a name which matches the specified pattern. This option may be specified multiple times to build a list of ignore patterns. The pattern follows the globbing rules documented in glob(7). Ignore patterns which end with a slash, “/”, will only match directories.

-m message

Use the specified log message when creating the new commit. Without the -m option, got import opens a temporary file in an editor where a log message can be written. Quitting the editor without saving the file will abort the import operation.

-r repository-path

Use the repository at the specified path. If not specified, assume the repository is located at or above the current working directory.

clone [-almqv] [-b branch] [-R reference] repository-URL [directory]

(alias: cl)

Clone a Git repository at the specified repository-URL into the specified directory. If no directory is specified, the directory name will be derived from the name of the cloned repository. got clone will refuse to run if the directory already exists.

The repository-URL specifies a protocol scheme, a server hostname, an optional port number separated from the hostname by a colon, and a path to the repository on the server: scheme://hostname:port/path/to/repository

The following protocol schemes are supported:

git

The Git protocol as implemented by the git-daemon(1) server. Use of this protocol is discouraged since it supports neither authentication nor encryption.

git+ssh

The Git protocol wrapped in an authenticated and encrypted ssh(1) tunnel. With this protocol the hostname may contain an embedded username for ssh(1) to use: user@hostname

ssh

Short alias for git+ssh.

Objects in the cloned repository are stored in a pack file which is downloaded from the server. This pack file will then be indexed to facilitate access to the objects stored within. If any objects in the pack file are stored in deltified form, all deltas will be fully resolved in order to compute the ID of such objects. This can take some time. More details about the pack file format are documented in git-repository(5).

got clone creates a remote repository entry in the got.conf(5) and config files of the cloned repository to store the repository-url and any branch or reference arguments for future use by got fetch or git-fetch(1).

The options for got clone are as follows:

-a

Fetch all branches from the remote repository's “refs/heads/” reference namespace and set fetch_all_branches in the cloned repository's got.conf(5) file for future use by got fetch. If this option is not specified, a branch resolved via the remote repository's HEAD reference will be fetched. Cannot be used together with the -b option.

-b branch

Fetch the specified branch from the remote repository's “refs/heads/” reference namespace. This option may be specified multiple times to build a list of branches to fetch. If the branch corresponding to the remote repository's HEAD reference is not in this list, the cloned repository's HEAD reference will be set to the first branch which was fetched. If this option is not specified, a branch resolved via the remote repository's HEAD reference will be fetched. Cannot be used together with the -a option.

-l

List branches and tags available for fetching from the remote repository and exit immediately. Cannot be used together with any of the other options except -q and -v.

-m

Create the cloned repository as a mirror of the original repository. This is useful if the cloned repository will not be used to store locally created commits.

The repository's got.conf(5) and config files will be set up with the “mirror” option enabled, such that got fetch or git-fetch(1) will write incoming changes directly to branches in the “refs/heads/” reference namespace, rather than to branches in the “refs/remotes/” namespace. This avoids the usual requirement of having to run got rebase or got merge after got fetch in order to make incoming changes appear on branches in the “refs/heads/” namespace. But maintaining custom changes in the cloned repository becomes difficult since such changes will be at risk of being discarded whenever incoming changes are fetched.

-q

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

-R reference

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

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

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

-v

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

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

(alias: co)

Copy files from a repository into a new work tree. Show the status of each affected file, using the following status codes:

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

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

The options for got checkout are as follows:

-b branch

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

-c commit

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

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

-E

Proceed with the checkout operation even if the directory at work-tree-path is not empty. Existing files will be left intact.

-p path-prefix

Restrict the work tree to a subset of the repository's tree hierarchy. Only files beneath the specified path-prefix will be checked out.

-q

Silence progress output.

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

(alias: up)

Update an existing work tree to a different commit. Change existing files in the work tree as necessary to match file contents of this commit. Preserve any local changes in the work tree and merge them with the incoming changes.

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

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

U	file was updated and contained no local changes
G	file was updated and local changes were merged cleanly
C	file was updated and conflicts occurred during merge
D	file was deleted
d	file's deletion was prevented by local modifications
A	new file was added
~	versioned file is obstructed by a non-regular file
!	a missing versioned file was restored
#	file was not updated because it contains merge conflicts
?	changes destined for an unversioned file were not merged

If no path is specified, update the entire work tree. Otherwise, restrict the update operation to files at or within the specified paths. Each path is required to exist in the update operation's target commit. Files in the work tree outside specified paths will remain unchanged and will retain their previously recorded base commit. Some cvg 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 cvg
m	modified file modes (executable bit only)
N	non-existent path specified on the command line

If no path is specified, show modifications in the entire work tree. Otherwise, show modifications at or within the specified paths.

If changes have been staged with got stage, staged changes are shown in the second output column, using the following status codes:

M	file modification is staged
A	file addition is staged
D	file deletion is staged

Changes created on top of staged changes are indicated in the first column:

MM	file was modified after earlier changes have been staged
MA	file was modified after having been staged for addition

The options for got status are as follows:

-I

Show unversioned files even if they match an ignore pattern.

-S status-codes

Suppress the output of files with a modification status matching any of the single-character status codes contained in the status-codes argument. Any combination of codes from the above list of possible status codes may be specified. For staged files, status codes displayed in either column will be matched. Cannot be used together with the -s option.

-s status-codes

Only show files with a modification status matching any of the single-character status codes contained in the status-codes argument. Any combination of codes from the above list of possible status codes may be specified. For staged files, status codes displayed in either column will be matched. Cannot be used together with the -S option.

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

log [-bdPpRs] [-C number] [-c commit] [-l N] [-r repository-path] [-S search-pattern] [-x commit] [path]

Display history of a repository. If a path is specified, show only commits which modified this path. If invoked in a work tree, the path is interpreted relative to the current working directory, and the work tree's path prefix is implicitly prepended. Otherwise, the path is interpreted relative to the repository root.

The options for got log are as follows:

-b

Display individual commits which were merged into the current branch from other branches. By default, got log shows the linear history of the current branch only.

-C number

Set the number of context lines shown in diffs with -p. By default, 3 lines of context are shown.

-c commit

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

-d

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

-l N

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

-P

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

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

Cannot be used with the -s option.

-p

Display the patch of modifications made in each commit. If a path is specified, only show the patch of modifications at or within this path. Cannot be used with the -s option.

-R

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

-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 cvg work tree, use the repository path associated with this work tree.

-S search-pattern

If specified, show only commits with a log message, author name, committer name, or ID SHA1 hash matched by the extended regular expression search-pattern. Lines in committed patches will be matched if -p is specified. File paths changed by a commit will be matched if -P is specified. Regular expression syntax is documented in re_format(7).

-s

Display a short one-line summary of each commit, instead of the default history format. Cannot be used together with the -p or -P option.

-x commit

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

diff [-adPsw] [-C number] [-c commit] [-r repository-path] [object1 object2 | path ...]

(alias: di)

When invoked within a work tree without any arguments, display all local changes in the work tree. If one or more path arguments are specified, only show changes within the specified paths.

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

The options for got diff are as follows:

-a

Treat file contents as ASCII text even if binary data is detected.

-C number

Set the number of context lines shown in the diff. By default, 3 lines of context are shown.

-c commit

Show differences between commits in the repository. This option may be used up to two times. When used only once, show differences between the specified commit and its first parent commit. When used twice, show differences between the two specified commits.

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

If the -c option is used, all non-option arguments will be interpreted as paths. If one or more such path arguments are provided, only show differences for the specified paths.

Cannot be used together with the -P option.

-d

Display diffstat of changes before the actual diff by annotating each file path or blob hash being diffed with the total number of lines added and removed. A summary line will display the total number of changes across all files.

-P

Interpret all arguments as paths only. This option can be used to resolve ambiguity in cases where paths look like tag names, reference names, or object IDs. This option is only valid when got diff is invoked in a work tree.

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

-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 cvg work tree, use the repository path associated with this work tree.

tree [-iR] [-c commit] [-r repository-path] [path]

(alias: tr)

Display a listing of files and directories at the specified directory path in the repository. Entries shown in this listing may carry one of the following trailing annotations:

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

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

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

The options for got tree are as follows:

-c commit

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

-i

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

-R

Recurse into sub-directories in the repository.

-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 cvg work tree, use the repository path associated with this work tree.

tag [-lVv] [-c commit] [-m message] [-r repository-path] [-s signer-id] name

Manage tags in a repository.

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

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

The options for got tag are as follows:

-c commit

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

-l

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

-m message

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

-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 cvg work tree, use the repository path associated with this work tree.

-s signer-id

While creating a new tag, sign this tag with the identity given in signer-id.

For SSH-based signatures, signer-id is the path to a file which may refer to either a private SSH key, or a public SSH key with the private half available via ssh-agent(1). got tag will sign the tag object by invoking ssh-keygen(1) with the -Y sign command, using the signature namespace “git” for compatibility with git(1).

-V

Verify tag object signatures. If a name is specified, show and verify the tag object with the provided name. Otherwise, list all tag objects and verify signatures where present.

got tag verifies SSH-based signatures by invoking ssh-keygen(1) with the options -Y verify -f allowed_signers. A path to the allowed_signers file must be set in got.conf(5), otherwise verification is impossible.

-v

Verbose mode. During SSH signature creation and verification this option will be passed to ssh-keygen(1). Multiple -v options increase the verbosity. The maximum is 3.

By design, the got tag command will not delete tags or change existing tags. If a tag must be deleted, the got ref command may be used to delete a tag's reference. This should only be done if the tag has not already been copied to another repository.

add [-IR] path ...

Schedule unversioned files in a work tree for addition to the repository in the next commit. By default, files which match a got status ignore pattern will not be added.

If a path mentioned in the command line is not an unversioned file then got add may raise an error. To avoid unnecessary errors from paths picked up by file globbing patterns in the shell, paths in the argument list will be silently ignored if they are not reported by got status at all, or if they are reported with one of the following status codes and do not have changes staged via got stage:

M	modified file
A	file scheduled for addition in next commit
C	modified or added file which contains merge conflicts
m	modified file modes (executable bit only)

The options for got add are as follows:

-I

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

-R

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

remove [-fkR] [-s status-codes] path ...

(alias: rm)

Remove versioned files from a work tree and schedule them for deletion from the repository in the next commit.

The options for got remove are as follows:

-f

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

-k

Keep affected files on disk.

-R

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

-s status-codes

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

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

patch [-nR] [-c commit] [-p strip-count] [patchfile]

(alias: pa)

Apply changes from patchfile to files in a work tree. Files added or removed by a patch will be scheduled for addition or removal in the work tree.

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

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

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

M	file was modified
G	file was merged using a merge-base found in the repository
C	file was merged and conflicts occurred during merge
D	file was deleted
A	file was added
#	failed to patch the file

If a change does not match at its exact line number, attempt to apply it somewhere else in the file if a good spot can be found. Otherwise, the patch will fail to apply.

cvg patch will refuse to apply a patch if certain preconditions are not met. Files to be deleted must already be under version control, and must not have been scheduled for deletion already. Files to be added must not yet be under version control and must not already be present on disk. Files to be modified must already be under version control and may not contain conflict markers.

If an error occurs, the patch operation will be aborted. Any changes made to the work tree up to this point will be left behind. Such changes can be viewed with got diff and can be reverted with got revert if needed.

The options for got patch are as follows:

-c commit

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

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

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

-n

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

-p strip-count

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

-R

Reverse the patch before applying it.

revert [-pR] [-F response-script] path ...

(alias: rv)

Revert any local changes in files at the specified paths in a work tree. File contents will be overwritten with those contained in the work tree's base commit. There is no way to bring discarded changes back after got revert!

If a file was added with got add, it will become an unversioned file again. If a file was deleted with got remove, it will be restored.

The options for got revert are as follows:

-F response-script

With the -p option, read “y”, “n”, and “q” responses line-by-line from the specified response-script file instead of prompting interactively.

-p

Instead of reverting all changes in files, interactively select or reject changes to revert based on “y” (revert change), “n” (keep change), and “q” (quit reverting this file) responses. If a file is in modified status, individual patches derived from the modified file content can be reverted. Files in added or deleted status may only be reverted in their entirety.

-R

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

commit [-CNnS] [-A author] [-F path] [-m message] [path ...]

(alias: ci)

Create a new commit in the repository from changes in a work tree and use this commit as the new base commit for the work tree. If no path is specified, commit all changes in the work tree. Otherwise, commit changes at or within the specified paths.

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

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

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

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

Files which are not part of the new commit will retain their previously recorded base commit. Some cvg commands may refuse to run while the work tree contains files from multiple base commits. The base commit of such a work tree can be made consistent by running got update across the entire work tree.

The got commit command requires the GOT_AUTHOR environment variable to be set, unless an author has been configured in got.conf(5) or Git's user.name and user.email configuration settings can be obtained from the repository's .git/config file or from Git's global ~/.gitconfig configuration file.

The options for got commit are as follows:

-A author

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

In addition to storing author information, the newly created commit object will retain “committer” information which is obtained, as usual, from the GOT_AUTHOR environment variable, or got.conf(5), or Git configuration settings.

-C

Allow committing files in conflicted status.

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

-F path

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

-m message

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

-N

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

-n

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

-S

Allow the addition of symbolic links which point outside of the path space that is under version control. By default, got commit will reject such symbolic links due to safety concerns. As a precaution, cvg 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.

cherrypick [-lX] [commit]

(alias: cy)

Merge changes from a single commit into the work tree. The specified commit should be on a different branch than the work tree's base commit. The expected argument is a reference or a commit ID SHA1 hash. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique.

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

G	file was merged
C	file was merged and conflicts occurred during merge
!	changes destined for a missing file were not merged
D	file was deleted
d	file's deletion was prevented by local modifications
A	new file was added
~	changes destined for a non-regular file were not merged
?	changes destined for an unversioned file were not merged

The merged changes will appear as local changes in the work tree, which may be viewed with got diff, amended manually or with further got cherrypick commands, committed with got commit.

If invoked in a work tree where no rebase, histedit, or merge operation is taking place, got cherrypick creates a record of commits which have been merged into the work tree. When a file changed by got cherrypick is committed with got commit, the log messages of relevant merged commits will then appear in the editor, where the messages should be further adjusted to convey the reasons for cherrypicking the changes. Upon exiting the editor, if the time stamp of the log message file is unchanged or the log message is empty, got commit will fail with an unmodified or empty log message error.

If all the changes in all files touched by a given commit are discarded, e.g. with got revert, this commit's log message record will also disappear.

got cherrypick will refuse to run if certain preconditions are not met. If the work tree contains multiple base commits, it must first be updated to a single base commit with got update. If any relevant files already contain merge conflicts, these conflicts must be resolved first.

The options for cvg cherrypick are as follows:

-l

Display a list of commit log messages recorded by cherrypick operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only show the log message of the specified commit.

If invoked in a work tree, only log messages recorded by cherrypick operations in the current work tree will be displayed. Otherwise, all commit log messages will be displayed irrespective of the work tree in which they were created. This option cannot be used with -X.

-X

Delete log messages created by previous cherrypick operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only delete the log message of the specified commit.

If invoked in a work tree, only log messages recorded by cherrypick operations in the current work tree will be deleted. Otherwise, all commit log messages will be deleted irrespective of the work tree in which they were created. This option cannot be used with -l.

backout [-lX] [commit]

(alias: bo)

Reverse-merge changes from a single commit into the work tree. The specified commit should be on the same branch as the work tree's base commit. The expected argument is a reference or a commit ID SHA1 hash. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique.

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

G	file was merged
C	file was merged and conflicts occurred during merge
!	changes destined for a missing file were not merged
D	file was deleted
d	file's deletion was prevented by local modifications
A	new file was added
~	changes destined for a non-regular file were not merged
?	changes destined for an unversioned file were not merged

The reverse-merged changes will appear as local changes in the work tree, which may be viewed with got diff, amended manually or with further got backout commands, committed with got commit.

If invoked in a work tree where no rebase, histedit, or merge operation is taking place, got backout creates a record of commits which have been reverse-merged into the work tree. When a file changed by got backout is committed with got commit, the log messages of relevant reverse-merged commits will then appear in the editor, where the messages should be further adjusted to convey the reasons for backing out the changes. Upon exiting the editor, if the time stamp of the log message file is unchanged or the log message is empty, got commit will fail with an unmodified or empty log message error.

If all the changes in all files touched by a given commit are discarded, e.g. with got revert, this commit's log message record will also disappear.

got backout will refuse to run if certain preconditions are not met. If the work tree contains multiple base commits, it must first be updated to a single base commit with got update. If any relevant files already contain merge conflicts, these conflicts must be resolved first.

The options for cvg backout are as follows:

-l

Display a list of commit log messages recorded by backout operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only show the log message of the specified commit.

If invoked in a work tree, only log messages recorded by backout operations in the current work tree will be displayed. Otherwise, all commit log messages will be displayed irrespective of the work tree in which they were created. This option cannot be used with -X.

-X

Delete log messages created by previous backout operations, represented by references in the “refs/got/worktree” reference namespace. If a commit is specified, only delete the log message of the specified commit.

If invoked in a work tree, only log messages recorded by backout operations in the current work tree will be deleted. Otherwise, all commit log messages will be deleted irrespective of the work tree in which they were created. This option cannot be used with -l.

cat [-P] [-c commit] [-r repository-path] arg ...

Parse and print contents of objects to standard output in a line-based text format. Content of commit, tree, and tag objects is printed in a way similar to the actual content stored in such objects. Blob object contents are printed as they would appear in files on disk.

Attempt to interpret each argument as a reference, a tag name, or an object ID SHA1 hash. References will be resolved to an object ID. Tag names will resolved to a tag object. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique.

If none of the above interpretations produce a valid result, or if the -P option is used, attempt to interpret the argument as a path which will be resolved to the ID of an object found at this path in the repository.

The options for got cat are as follows:

-c commit

Look up paths in the specified commit. If this option is not used, paths are looked up in the commit resolved via the repository's HEAD reference. The expected argument is a commit ID SHA1 hash or an existing reference or tag name which will be resolved to a commit ID. An abbreviated hash argument will be expanded to a full SHA1 hash automatically, provided the abbreviation is unique.

-P

Interpret all arguments as paths only. This option can be used to resolve ambiguity in cases where paths look like tag names, reference names, or object IDs.

-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 cvg work tree, use the repository path associated with this work tree.

info [path ...]

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

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

If one or more path arguments are specified, show additional per-file information for tracked files located at or within these paths. If a path argument corresponds to the work tree's root directory, display information for all tracked files.

ENVIRONMENT¶

GOT_AUTHOR

The author's name and email address, such as “Flan Hacker <flan_hacker@openbsd.org>”. Used by the got commit, got import, got rebase, got merge, and got histedit commands. Because git(1) may fail to parse commits without an email address in author data, cvg attempts to reject GOT_AUTHOR environment variables with a missing email address.

GOT_AUTHOR will be overridden by configuration settings in got.conf(5) or by Git's user.name and user.email configuration settings in the repository's .git/config file. The user.name and user.email configuration settings contained in Git's global ~/.gitconfig configuration file will only be used if neither got.conf(5) nor the GOT_AUTHOR environment variable provide author information.

GOT_IGNORE_GITCONFIG

If this variable is set then any remote repository definitions or author information found in Git configuration files will be ignored.

GOT_LOG_DEFAULT_LIMIT

The default limit on the number of commits traversed by got log. If set to zero, the limit is unbounded. This variable will be silently ignored if it is set to a non-numeric value.

VISUAL, EDITOR

The editor spawned by got commit, got histedit, got import, or got tag. If not set, the vi(1) text editor will be spawned.

FILES¶

got.conf

Repository-wide configuration settings for cvg. 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.

.cvg/got.conf

Worktree-specific configuration settings for cvg. If present, a got.conf(5) configuration file in the .cvg meta-data directory of a work tree supersedes any relevant settings in the repository's got.conf(5) configuration file and Git's config file.

EXIT STATUS¶

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

EXAMPLES¶

Enable tab-completion of cvg command names in ksh(1):

Clone an existing Git repository for use with cvg:

Unfortunately, many of the popular Git hosting sites do not offer anonymous access via SSH. Such sites will require an account to be created, and a public SSH key to be uploaded to this account, before repository access via ssh:// URLs will work.

Use of HTTP URLs currently requires git(1):

Alternatively, for quick and dirty local testing of cvg 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:

In a work tree, display files in a potentially problematic state:

Interactively revert selected local changes in a work tree directory:

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

As above, but list the most recently modified branches only:

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:

As above, but display changes in the order in which patch(1) could apply them in sequence:

In a work tree or a git repository directory, log the history of a subdirectory:

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

And this command has the same effect:

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

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.

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:

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 changes on the remote repository's “master” branch, making them visible on the local repository's “origin/master” branch:

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

Rebase the local “master” branch to merge the new changes that are now visible on the “origin/master” branch:

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:

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:

Additionally, the “mirror” option must be disabled:

Alternatively, the following git-fetch(1) 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 “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:

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 can be used to merge changes which are visible on the “origin/master” branch into the “master” branch. This will also merge local changes, if any, with the incoming changes:

In order to make changes committed to the “unified-buffer-cache” visible on the “master” branch, the “unified-buffer-cache” branch can be rebased onto the “master” branch:

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:

On the “master” branch, log messages for local changes can now be amended with “OK” by other developers and any other important new information:

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:

If the remote repository requires the HTTPS protocol, the git-push(1) command must be used instead:

When making contributions to projects which use the “pull request” workflow, SSH protocol repository access needs to be set up first. Once an account has been created on a Git hosting site it should be possible to upload a public SSH key for repository access authentication.

The “pull request” workflow will usually involve two remote repositories. In the real-life example below, the “origin” repository was forked from the “upstream” repository by using the Git hosting site's web interface. The got.conf(5) file in the local repository describes both remote repositories:

# Jelmers's repository, which accepts pull requests
remote "upstream" {
	server git@github.com
	protocol ssh
	repository "/jelmer/dulwich"
	branch { "master" }
}

# Stefan's fork, used as the default remote repository
remote "origin" {
	server git@github.com
	protocol ssh
	repository "/stspdotname/dulwich"
	branch { "master" }
}

With this configuration, Stefan can create commits on “refs/heads/master” and send them to the “origin” repository by running:

The changes can now be proposed to Jelmer by opening a pull request via the Git hosting site's web interface. If Jelmer requests further changes to be made, additional commits can be created on the “master” branch and be added to the pull request by running got send again.

If Jelmer prefers additional commits to be “squashed” then the following commands can be used to achieve this:

In addition to reviewing the pull request in the web user interface, Jelmer can fetch the pull request's branch into his local repository and create a local branch which contains the proposed changes:

Once Jelmer has accepted the pull request, Stefan can fetch the merged changes, and possibly several other new changes, by running:

The merged changes will now be visible under the reference “refs/remotes/upstream/master”. The local “master” branch can now be rebased on top of the latest changes from upstream:

As an alternative to got rebase, branches can be merged with got merge:

The question of whether to rebase or merge branches is philosophical. When in doubt, refer to the software project's policies set by project maintainers.

As a final step, the forked repository's copy of the master branch needs to be kept in sync by sending the new changes there:

If multiple pull requests need to be managed in parallel, a separate branch must be created for each pull request with got branch. Each such branch can then be used as above, in place of “refs/heads/master”. Changes for any accepted pull requests will still appear under “refs/remotes/upstream/master,” regardless of which branch was used in the forked repository to create a pull request.

SEE ALSO¶

gotadmin(1), tog(1), git-repository(5), got-worktree(5), got.conf(5), gotwebd(8)

AUTHORS¶

Anthony J. Bentley <bentley@openbsd.org>
Christian Weisgerber <naddy@openbsd.org>
Hiltjo Posthuma <hiltjo@codemadness.org>
Josh Rickmar <jrick@zettaport.com>
Joshua Stein <jcs@openbsd.org>
Klemens Nanni <kn@openbsd.org>
Martin Pieuchot <mpi@openbsd.org>
Neels Hofmeyr <neels@hofmeyr.de>
Omar Polo <op@openbsd.org>
Ori Bernstein <ori@openbsd.org>
Sebastien Marie <semarie@openbsd.org>
Stefan Sperling <stsp@openbsd.org>
Steven McDonald <steven@steven-mcdonald.id.au>
Theo Buehler <tb@openbsd.org>
Thomas Adam <thomas@xteddy.org>
Tracey Emery <tracey@traceyemery.net>
Yang Zhong <yzhong@freebsdfoundation.org>

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

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

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

CAVEATS¶

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