commit 8797b2280033741ca768a2317dbd0a0312e73c4e from: Stefan Sperling date: Sun Aug 04 13:26:47 2019 UTC initial got website commit - /dev/null commit + 8797b2280033741ca768a2317dbd0a0312e73c4e blob - /dev/null blob + 4c402acc49affdd54c68c8f3fb2d6b50700a0a53 (mode 644) --- /dev/null +++ git-repository.5.html @@ -0,0 +1,212 @@ + + + + + + + GIT-REPOSITORY(5) + + + + + + + + +
GIT-REPOSITORY(5)File Formats ManualGIT-REPOSITORY(5)
+
+
+

+git-repository — +
Git repository format
+
+
+

+A Git repository stores a series of versioned snapshots of a file hierarchy. + Conceptually, the repository's data model is a directed acyclic graph which + contains three types of objects as nodes: +
+
Blobs
+
The content of tracked files is stored in objects of type + blob.
+
Trees
+
A tree object points to any number of such blobs, and + also to other trees in order to represent a hierarchy of files and + directories.
+
Commits
+
A commit object points to the root element of one tree, + and thus records the state of this entire tree as a snapshot. Commit + objects are chained together to form lines of version control history. + Most commits have just one successor commit, but commits may be succeeded + by an arbitrary number of subsequent commits so that diverging lines of + version control history, known as branches, can be + represented. A commit which precedes another commit is referred to as that + other commit's parent commit. A commit with multiple + parents unites disparate lines of history and is known as a + merge commit.
+
+

Each object is identified by a SHA1 hash calculated over both the + object's header and the data stored in the object.

+
+
+

+Loose objects are stored as individual files beneath the directory + objects, spread across 256 sub-directories named after + the 256 possible hexadecimal values of the first byte of an object identifier. + The name of the loose object file corresponds to the remaining hexadecimal + byte values of the object's identifier. +

A loose object file begins with a header which specifies the type + of object as an ASCII string, followed by an ASCII space character, followed + by the object data's size encoded as an ASCII number string. The header is + terminated by a NUL character, and the remainder of the + file contains object data. Loose objects files are compressed with + deflate(3).

+

Multiple objects can be bundled in a pack file + for better disk space efficiency and increased run-time performance. The + pack file format knows two additional types of objects in addition to blobs, + trees, and commits:

+
+
Offset Delta Objects
+
This object is represented as a delta against another object in the same + pack file. This other object is referred to by its offset in the pack + file.
+
Reference Delta Objects
+
This object is represented as a delta against another object in the same + pack file. The other object is referred to by its SHA1 object + identifier.
+
+

Pack files are self-contained and may not refer to loose objects + or objects stored in other pack files. Deltified objects may refer to other + deltified objects as their delta base, forming chains of deltas. The + ultimate base of a delta chain must be an object of the same type as the + original object which is stored in deltified form.

+

Each pack file is accompanied by a corresponding + pack index file, which lists the IDs and offsets of all + objects contained in the pack file.

+
+
+

+A reference associates a name with an object ID. A prominent use of references + is providing names to branches in the repository by pointing at commit objects + which represent the current tip commit of a branch. Because references may + point to arbitrary object IDs their use is not limited to branches. +

The name is a UTF-8 string with the following disallowed + characters: ‘ ’ (space), ~ (tilde), ^ (caret), : + (colon), ? (question mark), * (asterisk), [ (opening square bracket), \ + (backslash). Additionally, the name may not contain the two-character + sequences //, .. , and @{.

+

Reference names may optionally have multiple components separated + by the / (slash) character, forming a hierarchy of reference namespaces. Got + reserves the got/ reference namespace for internal + use.

+

A symbolic reference associates a name with the name of another + reference. The most prominent example is the HEAD + reference which points at the name of the repository's default branch + reference.

+

References are stored either as a plain file within the + repository, typically under the refs/ directory, or + in the packed-refs file which contains one reference + definition per line.

+

Any object which is not directly or indirectly reachable via a + reference is subject to deletion by Git's garbage collector.

+
+
+

+
+
HEAD
+
A reference to the current head commit of the Git work tree. In bare + repositories, this files serves as a default reference.
+
ORIG_HEAD
+
Reference to original head commit. Set by some Git operations.
+
FETCH_HEAD
+
Reference to a branch tip commit most recently fetched from another + repository.
+
branches/
+
Legacy directory used by the deprecated Gogito Git interface.
+
config
+
Git configuration file. See git-config(1).
+
description
+
A human-readable description of the repository.
+
hooks/
+
This directory contains hook scripts to run when certain events + occur.
+
index
+
The file index used by git(1). This file is not used by + got(1), which uses the got-worktree(5) + file index instead.
+
info
+
Various configuration items.
+
logs/
+
Directory where reflogs are stored.
+
objects/
+
Loose and packed objects are stored in this directory.
+
packed-refs
+
A file which stores references. Corresponding on-disk references take + precedence over those stored here.
+
refs/
+
The default directory to store references in.
+
+

A typical Git repository exposes a work tree which allows the user + to make changes to versioned files and create new commits. When a Git work + tree is present, the actual repository data is stored in a + .git subfolder of the repository's root directory. A + Git repository without a work tree is known as a “bare” + repository. got(1) does not make use of Git's work tree + and treats every repository as if it was bare.

+
+
+

+got(1), deflate(3), + SHA1(3), got-worktree(5) +
+
+

+The Git repository format was initially designed by Linus Torvalds in 2005 and + has since been extended by various people involved in the development of the + Git version control system. +
+
+

+The particular set of disallowed characters in reference names is a consequence + of design choices made for the command-line interface of + git(1). The same characters are disallowed by Got for + compatibility purposes. Got additionaly prevents users from creating reference + names with a leading - (dash) character, because this is rarely intended and + not considered useful. +
+
+ + + + + +
August 4, 2019OpenBSD 6.5
+ + blob - /dev/null blob + 7cf6d3904d98ef99fa3f0a28e5d1e40683739145 (mode 644) --- /dev/null +++ goals.html @@ -0,0 +1,44 @@ + + + + +Game of Trees (Got): Goals + + + + + +

+ +Game of Trees +Goals +

+
+ + blob - /dev/null blob + 640cca1ba2eba696debc48075c713934560f42d6 (mode 644) --- /dev/null +++ got-worktree.5.html @@ -0,0 +1,141 @@ + + + + + + + GOT-WORKTREE(5) + + + + + + + + +
GOT-WORKTREE(5)File Formats ManualGOT-WORKTREE(5)
+
+
+

+got-worktree — +
got worktree format
+
+
+

+A got work tree stores a file hierarchy which corresponds to a + versioned snapshot stored in a Git repository. The work tree's meta data is + stored in the .got directory. A work tree is created + with got checkout and is required to make changes to a + Git repository with got(1). +

A work tree stores the path to its Git repository, the name of a + reference to the branch which files were checked out from, and the ID of a + commit on this branch known as the base commit.

+

File meta-data is stored in a structured file called the + file index and tracks the status of file modifications, + additions, and deletions, relative to the base commit in the repository. The + file index contains a series of records, and each such record contains the + following status information for a particular file:

+
+
Copy of filesystem meta-data
+
Timestamp, file size, and file ownership information from + stat(2). This is only used to detect file modifications + and is never applied back to the filesystem. File permissions are not + tracked, except for the executable bit. When versioned files are checked + out into the work tree, the current umask(2) is + heeded.
+
Blob object ID
+
The SHA1 hash of the blob object which corresponds to the contents of this + file in the repository. The hash is stored as binary data.
+
Commit object ID
+
The SHA1 hash of the commit object the file was checked out from. The hash + is stored as binary data. This data is used to detect past incomplete + update operations. Entries which do not match the work tree's base commit + may still need to be updated to match file content stored in the base + commit.
+
Flags
+
A flags field (intentionally not documented).
+
Path data
+
The path of the entry, relative to the work tree root. Path data is of + variable length and NUL-padded to a multiple of 8 bytes.
+
+

A corrupt or missing file index can be recreated on demand with + got update. When the file index is modified, it is + read into memory in its entirety, modified in place, and written to a + temporary file. This temporary file is then moved on top of the old file + index with rename(2). This ensures that no other processes + see an inconsistent file index which is in the process of being written.

+

Work tree meta data must only be modified while the work tree's + lock file has been exclusively locked with + lockf(3).

+

Each work tree has a universal unique identifier. When a work tree + is checked out or updated, this identifier is used to create a reference to + the current base commit in the Git repository. The presence of this + reference prevents Git garbage collectors from discarding the base commit + and any objects it refers to. When a work tree is no longer needed its + reference can be deleted from the Git repository with got + ref -d.

+
+
+

+
+
.got
+
Meta-data directory where all files listed below reside.
+
base-commit
+
SHA1 hex-string representation of the current base commit.
+
file-index
+
File status information.
+
format
+
Work tree format number.
+
head-ref
+
Name of the reference to the current branch.
+
lock
+
Lock file to obtain exclusive write access to meta data.
+
path-prefix
+
Path inside repository the work tree was checked out from.
+
repository
+
Path to the repository the work tree was checked out from.
+
uuid
+
A universal unique identifier for the work tree.
+
+
+
+

+got(1), rename(2), + stat(2), umask(2), + lockf(3), git-repository(5) +
+
+ + + + + +
August 4, 2019OpenBSD 6.5
+ + blob - /dev/null blob + b6bb9cac6ed249ef0cad685b99f35ca41c96dc20 (mode 644) --- /dev/null +++ got.1.html @@ -0,0 +1,1238 @@ + + + + + + + GOT(1) + + + + + + + + +
GOT(1)General Commands ManualGOT(1)
+
+
+

+got — +
game of trees
+
+
+

+ + + + + +
gotcommand [-h] + [arg ...]
+
+
+

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

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

+

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

+

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

+
+
+
Display usage information.
+
+
Display program version and exit immediately.
+
+

The commands for got are as follows:

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

+
+
+
Short alias for init.
+
+ [-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.

+

The options for got import are as + follows:

+
+
+ branch
+
Create the specified branch instead of creating + the default branch “master”. Use of this option is + required if the “master” branch already exists.
+
+ 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.
+
+ repository-path
+
Use the repository at the specified path. If not specified, assume the + repository is located at or above the current working directory.
+
+ 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).
+
+
+
+
Short alias for import.
+
+ [-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:

+
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+
+
+
Short alias for checkout.
+
+ [-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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ufile was updated and contained no local changes
Gfile was updated and local changes were merged cleanly
Cfile was updated and conflicts occurred during merge
Dfile was deleted
Anew 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 comitted with + got commit or unstaged with got + unstage.

+

The options for got update are as + follows:

+
+
+ 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.
+
+ commit
+
Update the work tree to the specified commit. + The expected argument is a commit ID SHA1 hash or an existing + reference 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.
+
+
+
+
Short alias for update.
+
+ [path ...]
+
Show the current modification status of files in a work tree, using the + following status codes: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Mmodified file
Afile scheduled for addition in next commit
Dfile scheduled for deletion in next commit
Cmodified 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
+

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:

+ + + + + + + + + + + + + +
Mfile modification is staged
Afile addition is staged
Dfile deletion is staged
+

If a path has staged changes, modification status of files + shown in the first output column is relative to the staged changes:

+ + + + + + + + + +
MMmodified file was modified again after being staged
MAadded file was modified after being staged
+
+
+
Short alias for status.
+
+ [-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:

+
+
+ commit
+
Start traversing history at the specified + commit. The expected argument is a commit ID + SHA1 hash or an existing reference 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.
+
+ number
+
Set the number of context lines shown in diffs with + -p. By default, 3 lines of context are + shown.
+
+
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.
+
+ N
+
Limit history traversal to a given number of commits.
+
+
Display the patch of modifications made in each commit.
+
+ 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.
+
+
+
+ [-C number] + [-r repository-path] + [-s] [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, or an object ID SHA1 hash, and display differences between + these 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:

+
+
+ number
+
Set the number of context lines shown in the diff. By default, 3 lines + of context are shown.
+
+ 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.
+
+
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.
+
+
+
+
Short alias for diff.
+
+ [-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:

+
+
+ commit
+
Start traversing history at the specified + commit. The expected argument is a commit ID + SHA1 hash or an existing reference 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.
+
+ 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.
+
+
+
+
Short alias for blame.
+
+ [-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 directory
*entry is an executable file
+

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:

+
+
+ 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 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.
+
+ 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.
+
+
Show object IDs of files (blob objects) and directories (tree + objects).
+
+
Recurse into sub-directories in the repository.
+
+
+
+
Short alias for tree.
+
+ [-r repository-path] + [-l] [-d + name] [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 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:

+
+
+ 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.
+
+
List all existing references in the repository.
+
+ name
+
Delete the reference with the specified name from the repository.
+
+
+
+ [-r repository-path] + [-l] [-d + name] [name + [base-branch]]
+
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 no options are passed, expect one or two arguments and + attempt to create a branch with the given name, + and make it point at the given base-branch. If no + base-branch is specified, default to the work + tree's current branch if invoked in a work tree, or to the repository's + HEAD reference.

+

The options for got branch are as + follows:

+
+
+ 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.
+
+
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
+
+
+ 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.
+
+
+
+
Short alias for branch.
+
+ file-path ...
+
Schedule unversioned files in a work tree for addition to the repository + in the next commit.
+
+ 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:

+
+
+
Perform the operation even if a file contains uncommitted + modifications.
+
+
+
+
Short alias for remove.
+
+ file-path ...
+
Revert any uncommited 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.

+
+
+
Short alias for revert.
+
+ [-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:

+ + + + + + + + + + + + + +
Mmodified file
Dfile was deleted
Anew file was added
+

Files without local changes 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.

+

The options for got commit are as + follows:

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

+
+
+
Short alias for commit.
+
+ 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:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Gfile was merged
Cfile was merged and conflicts occurred during merge
!changes destined for a missing file were not merged
Dfile was deleted
dfile's deletion was obstructed by local modifications
Anew 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 comands, + 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.

+
+
+
Short alias for cherrypick.
+
+ 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:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Gfile was merged
Cfile was merged and conflicts occurred during merge
!changes destined for a missing file were not merged
Dfile was deleted
dfile's deletion was obstructed by local modifications
Anew 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 + comands, 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.

+
+
+
Short alias for backout.
+
+ [-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 descendent 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:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Gfile was merged
Cfile was merged and conflicts occurred during merge
!changes destined for a missing file were not merged
Dfile was deleted
dfile's deletion was obstructed by local modifications
Anew 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 comitted + 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:

+
+
+
Abort an interrupted rebase operation. If this option is used, no + further command-line arguments are allowed.
+
+
Continue an interrupted rebase operation. If this option is used, no + further command-line arguments are allowed.
+
+
+
+
Short alias for rebase.
+
+ [-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 commitUse the specified commit as it is.
edit commitUse the specified commit but once changes have been merged into the + work tree interrupt the histedit operation for amending.
fold commitCombine the specified commit with the next commit listed further + below that will be used.
drop commitRemove this commit from the edited history.
mesg log-messageUse 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:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Gfile was merged
Cfile was merged and conflicts occurred during merge
!changes destined for a missing file were not merged
Dfile was deleted
dfile's deletion was obstructed by local modifications
Anew 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 comitted + 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:

+
+
+
Abort an interrupted histedit operation. If this option is used, no + further command-line arguments are allowed.
+
+
Continue an interrupted histedit operation. If this option is used, no + further command-line arguments are allowed.
+
+
+
+
Short alias for histedit.
+
+ [-l] file-path ...
+
Stage local changes at the specified paths for inclusion in the next + commit. Paths may be staged if they are added, modified, or deleted + according to got status. +

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 relative to staged changes.

+

The options for got stage are as + follows:

+
+
+
Instead of staging new changes, list paths which are already staged, + along with the IDs of corresponding blob objects. Indicate staged + status using the following status codes: + + + + + + + + + + + + + +
Afile addition is staged
Mfile modification is staged
Dfile deletion is staged
+
+
+

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.

+
+
+
Short alias for stage.
+
+ [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. +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Gfile was unstaged
Cfile was unstaged and conflicts occurred during merge
!changes destined for a missing file were not merged
Dfile was staged as deleted and still is deleted
dfile's deletion was obstructed by local modifications
~changes destined for a non-regular file were not merged
+
+
+
Short alias for unstage.
+
+
+
+

+
+
+
The author's name and email address for got commit + and got import, for example: + Stefan Sperling + <stsp@openbsd.org>
+
+ EDITOR
+
The editor spawned by got commit.
+
+
+
+

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

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

+
$ cd /var/git/
+
$ git clone --bare + https://github.com/openbsd/src.git
+

Alternatively, for quick and dirty local testing of + got a new Git repository could be created and + populated with files, e.g. from a temporary CVS checkout located at + /tmp/src:

+

+
$ got init + /var/git/src.git
+
$ got import -r /var/git/src.git -I + CVS -I obj /tmp/src
+

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

+

+
$ got checkout /var/git/src.git + /usr/src
+

View local changes in a work tree directory:

+

+
$ got status
+
$ got diff | less
+

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

+

+
$ got branch -l
+

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

+

+
$ got branch unified-buffer-cache + master
+

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

+

+
$ got update -b + unified-buffer-cache
+

Create a new commit from local changes in a work tree directory. + This new commit will become the head commit of the work tree's current + branch:

+

+
$ got commit
+

In a work tree or a git repository directory, view changes + committed in the 3 most recent commits to the work tree's branch, or the + branch resolved via the repository's HEAD reference, respectively:

+

+
$ got log -p -l 3 -f
+

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

+

+
$ got add + sys/uvm/uvm_ubc.c
+
$ got remove + sys/uvm/uvm_vnode.c
+

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

+

+
$ got commit -m 'unify the buffer + cache'
+

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

+

+
$ got update
+

Roll file content on the unified-buffer-cache branch back by one + commit, and then fetch the rolled-back change into the work tree as a local + change to be amended and perhaps committed again:

+

+
$ got backout + unified-buffer-cache
+
$ got commit -m 'roll back + previous'
+
$ # now back out the previous backout + :-)
+
$ got backout + unified-buffer-cache
+

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

+

+
$ cd /var/git/src.git
+
$ git fetch origin + master:master
+

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

+

+
$ got update -b master
+
$ got rebase + unified-buffer-cache
+

Create a patch from all changes on the unified-buffer-cache + branch. The patch can be mailed out for review and applied to OpenBSD's CVS + tree:

+

+
$ got diff master + unified-buffer-cache > /tmp/ubc.diff
+

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

+

+
$ got update -b + unified-buffer-cache
+
$ got update -c master
+
$ got histedit
+

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:

+

+
$ cd /var/git/repo
+
$ git config remote.origin.fetch + '+refs/heads/*:refs/remotes/origin/*'
+

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

+

+
[remote origin]
+
url = ...
+
fetch = + +refs/heads/*:refs/remotes/origin/*
+

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:

+

+
$ cd /var/git/repo
+
$ 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:

+

+
$ got update -b + origin/master
+
$ got rebase master
+

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

+

+
$ cd /var/git/repo
+
$ git push origin master
+
+
+

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

+Stefan Sperling + <stsp@openbsd.org> +
+Martin Pieuchot + <mpi@openbsd.org> +
+joshua stein + <jcs@openbsd.org> +
+
+

+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. +
+
+ + + + + +
August 4, 2019OpenBSD 6.5
+ + blob - /dev/null blob + 97ace786464b193baf1cd51e54016aea3016e62f (mode 644) Binary files /dev/null and got.png differ blob - /dev/null blob + 627271783e42d3e398372616e05d46102ff9b4fa (mode 644) --- /dev/null +++ index.html @@ -0,0 +1,62 @@ + + + + Game of Trees + + + + + + + +
+ +

About Got

+ +

Resources

+ +

For OpenBSD

+ + + + 		+

+ [Game of Trees] +

+ +

+ Got is to be released soon. + +

+Game of Trees (Got) is a version control system which prioritizes ease +of use and simplicity over flexibility. + +

+Got is being developed exclusively on +OpenBSD. It is not a drop-in +replacement for other version control systems and it does not attempt +to compete with anything else than the use of other version control +systems in the context of the OpenBSD project. +Got's target audience are OpenBSD developers, and its focus is directed +at the particular needs and use cases of the OpenBSD project. + +

+Game of Trees is developed by Stefan Sperling +with help from other OpenBSD developers. +The software is freely usable and re-usable by everyone under +a BSD license. + + +

blob - /dev/null blob + e9984c2ddffaab9e0dc33772ad316239b3eb7de1 (mode 644) --- /dev/null +++ manual.html @@ -0,0 +1,22 @@ + + + + +Game of Trees Manual Pages + + + + + +

+ +Game of Trees +Manual Pages +

+
+ blob - /dev/null blob + 2b0849318b79f0d8454a3531d30f88c1da427faf (mode 644) --- /dev/null +++ openbsd.css @@ -0,0 +1,320 @@ +/* $OpenBSD: openbsd.css,v 1.9 2019/06/03 02:43:03 deraadt Exp $ */ + +:root { + --red: #E00000; + --green: #008100; + --blue: #0000E0; + --buildhead: #E0E0E0; +} + +:link { + color: #23238E; +} + +:visited { + color: #008088; +} + +body { + background-color: #FFFFFF; + color: #111111; + margin: 15px auto; + padding: 0 10px; +} + +code { + white-space: nowrap; +} + +@media (min-width: 800px) { + body { + max-width: 85%; + } +} + +tt { + white-space: pre; +} + +.cmdbox { + background: #F5F5F5; + border: 1px solid #AAAAAA; + overflow: auto; + padding: 10px; +} + +#OpenBSD { + color: #E00000; +} + +#OpenBSD :link i, #OpenBSD :visited i { + color: #0000FF; +} + +#OpenBSD :link b, #OpenBSD :visited b { + color: #000084; +} + +#OpenBSD small { + font-weight: normal; + float: right; +} + +/* sidebar layout */ + +#project-main { + height: 100%; + border-collapse: collapse; + position: absolute; + bottom: 0; + left: 0; + right: 0; + top: 0; +} + +#project-main td { + padding: 4px; +} + +#project-main tr td:first-child { + border-right: 11px solid; +} + +#project-main tr td:first-child { + background-color: #6BBDD6; + border-color: #007B9C; +} + +#project-main.not-openbsd tr td:first-child { + background-color: #6BBDD6; + border-color: #007B9C; +} + +#project-main tr td:first-child h1 { + margin: 0; + font-size: 15pt; + white-space: nowrap; +} + +#project-main tr td:first-child ul { + margin-top: 0; + margin-bottom: 1em; + padding-left: 0; +} + +#project-main tr td:first-child ul li { + list-style-type: none; + list-style-position: inside; + margin-left: 0.5em; +} + +#project-main .header { + margin: 0; + text-align: center; +} + +#callout { + color: #E00000; + font-weight: bold; + text-align: center; +} + +.not-openbsd #callout { + color: #0000A0; + font-weight: normal; +} + +#project-main .align-top { + vertical-align: top; +} + +#project-main .align-bottom { + vertical-align: bottom; +} + +/* errataXX.html */ + +#errata strong { + color: var(--green); +} + +/* XX.html */ + +#release #OpenBSD + table { + border-spacing: 0; + margin-bottom: 1.5em; +} + +#release #OpenBSD + table td { + vertical-align: top; +} + +#release #OpenBSD + table > tbody > tr > td { + padding-left: 1.4em; +} + +#release #OpenBSD + table ul { + margin-left: 0; + padding-left: 0; +} + +#release #OpenBSD + table ul li { + margin-left: 0; + padding-left: 0; +} + +#release cite.isbn { + color: var(--red); + font-style: normal; +} + +#release code.reldir { + color: var(--red); + font-family: serif; +} + +#release table.signify { + font-family: monospace; +} + +#release table.signify td { + padding: 0; +} + +#release h3 { + color: var(--blue); +} + +#release #quickinstall h3 { + color: var(--red); +} + +#release kbd { + font-weight: bolder; +} + +#release #new li p { + margin-bottom: 0; +} + +#release #new li p + p { + margin-top: 0; +} + +#release #new li + li { + margin-top: 1em; +} + +#release #new li li + li { + margin-top: 0; +} + +#release #new li li ul { + margin-bottom: 0; +} + +#release #quickinstall p:first-child { + margin-left: 0; +} + +#release #quickinstall p { + margin-left: 2.5em; +} + +#release #quickinstall blockquote { + margin-left: 4.5em; +} + +/* platform pages */ + +#platform #OpenBSD + hr + table { + margin-bottom: 0; +} +#platform #OpenBSD + hr + table tr { + margin-left: 0; +} + +#platform #OpenBSD + hr + table td { + vertical-align: top; + padding-left: 0; + padding-bottom: 0; +} + +#platform #OpenBSD + hr + table p { + margin-top: 0; +} + +#platform #OpenBSD + hr + table p:last-child { + margin-bottom: 0; +} + +#platform h3 { + color: var(--blue); +} + +/* redefine colors for dark mode */ + +@media (prefers-color-scheme: dark) { + :root { + --red: #E05434; + --green: #20B700; + --blue: #A7C1E5; + --buildhead: #474749; + } + + :link { + color: #BAD7FF; + } + + :visited { + color: #F6BAFF; + } + + body { + background-color: #1E1F21; + color: #EEEFF1; + } + + .cmdbox { + background: #000000; + color: #FFFFFFF; + } + + #OpenBSD :link { + text-decoration-color: #CF4229; + } + + #OpenBSD :link i, #OpenBSD :visited i { + color: #F2CA30; + } + + #OpenBSD :link b, #OpenBSD :visited b { + color: #CF4229; + } + + #OpenBSD { + color: #EEEFF1; + } + + #faq #OpenBSD small :link { + text-decoration-color: #BAD7FF; + } + + #project-main tr td:first-child { + background-color: #202F51; + border-color: #97BADB; + } + + #project-main.not-openbsd tr td:first-child { + background-color: #202F51; + border-color: #97BADB; + } + + #callout { + color: #E05434; + } + + .not-openbsd #callout { + color: #E05434; + } +} blob - /dev/null blob + f5c7738b51ed6a308fbc963b2e4ebe4d85343829 (mode 644) --- /dev/null +++ tog.1.html @@ -0,0 +1,341 @@ + + + + + + + TOG(1) + + + + + + + + +
TOG(1)General Commands ManualTOG(1)
+
+
+

+tog — +
git repository browser
+
+
+

+ + + + + +
togcommand [-h] + [arg ...]
+
+
+

+tog is an interactive read-only browser for git + repositories. This repository format is described in + git-repository(5). +

tog supports several types of views which + display repository data:

+
+
Log view
+
Displays commits in the repository's history. This view is displayed + initially if no command is specified.
+
Diff view
+
Displays changes made in a particular commit.
+
Blame view
+
Displays the line-by-line history of a file.
+
Tree view
+
Displays the tree corresponding to a particular commit.
+
+

tog provides global and command-specific + key bindings and options. The global key bindings are:

+
+
+
Quit tog.
+
+
Quit the view which is in focus.
+
+
Switch focus between views.
+
+
Toggle fullscreen mode for a split-screen view. + tog will automatically use split-screen views if + the size of the terminal window is sufficiently large.
+
+

Global options must precede the command name, and are as + follows:

+
+
+
Display usage information.
+
+
Display program version and exit immediately.
+
+

The commands for tog are as follows:

+
+
+ [-c commit] + [-r repository-path] + [path]
+
Display history of a repository. If a path is + specified, show only commits which modified this path. +

This command is also executed if no explicit command is + specified.

+

The key bindings for tog log are as + follows:

+
+
+
Move the selection cursor down.
+
+
Move the selection cursor up.
+
+
Move the selection cursor down one page.
+
+
Move the selection cursor up one page.
+
+
Open a diff view showing file changes made in + the currently selected commit.
+
+
Open a tree view showing the tree for the + currently selected commit.
+
+
Show log entries for the parent directory of the currently selected + path, unless an active search is in progress in which case + Backspace aborts the search.
+
+
Prompt for a search pattern and start searching for matching commits. + The search pattern is an extended regular expression which is matched + against a commit's author name, committer name, log message, and + commit ID SHA1 hash. Regular expression syntax is documented in + re_format(7).
+
+
Find the next commit which matches the current search pattern. + Searching continues until either a match is found or the + Backspace key is pressed.
+
+
Find the previous commit which matches the current search pattern. + Searching continues until either a match is found or the + Backspace key is pressed.
+
+
Reload the log view with new commits found in the repository.
+
+

The options for tog log are as + follows:

+
+
+ commit
+
Start traversing history at the specified + commit. The expected argument is the name of a + branch or a commit ID SHA1 hash. 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.
+
+ repository-path
+
Use the repository at the specified path. If not specified, assume the + repository is located at or above the current working directory.
+
+
+
+ [repository-path] object1 + object2
+
Display the differences between two objects in the repository. Each + object argument is an object ID SHA1 hash. An + abbreviated hash argument will be expanded to a full SHA1 hash + automatically, provided the abbreviation is unique. Both objects must be + of the same type (blobs, trees, or commits). If the + repository path is omitted, use the current working + directory. +

The key bindings for tog diff are as + follows:

+
+
+
Scroll down.
+
+
Scroll up.
+
+
Scroll down one page.
+
+
Scroll up one page.
+
[
+
Reduce the amount of diff context lines.
+
]
+
Increase the amount of diff context lines.
+
+
If the diff view was opened via the log view, move to the previous + (younger) commit.
+
+
If the diff view was opened via the log view, move to the next (older) + commit.
+
+
+
+ [-c commit] + [-r repository-path] + path
+
Display line-by-line history of a file at the specified path. +

The key bindings for tog blame are as + follows:

+
+
+
Move the selection cursor down.
+
+
Move the selection cursor up.
+
+
Open a diff view for the currently selected + line's commit.
+
+
Reload the blame view with the version of the + file as found in the currently selected line's commit.
+
+
Reload the blame view with the version of the + file as found in the parent commit of the currently selected line's + commit.
+
+
Reload the blame view with the previously + blamed commit.
+
+
Prompt for a search pattern and start searching for matching line. The + search pattern is an extended regular expression. Regular expression + syntax is documented in re_format(7).
+
+
Find the next line which matches the current search pattern.
+
+
Find the previous line which matches the current search pattern.
+
+

The options for tog blame are as + follows:

+
+
+ commit
+
Start traversing history at the specified + commit. The expected argument is the name of a + branch or a commit ID SHA1 hash. An abbreviated hash argument will be + expanded to a full SHA1 hash automatically, provided the abbreviation + is unique.
+
+ repository-path
+
Use the repository at the specified path. If not specified, assume the + repository is located at or above the current working directory.
+
+
+
+ [-c commit] + [repository-path]
+
Display the repository tree. If the repository path + is omitted, assume the repository is located in the current working + directory. +

The key bindings for tog tree are as + follows:

+
+
+
Move the selection cursor down.
+
+
Move the selection cursor up.
+
+
Enter the currently selected directory, or switch to the + blame view for the currently selected + file.
+
+
Open a log view for the currently selected + tree entry.
+
+
Move back to the parent directory.
+
+
Show object IDs for all objects displayed in the + tree view.
+
+
Prompt for a search pattern and start searching for matching tree + entries. The search pattern is an extended regular expression which is + matched against the tree entry's name. Regular expression syntax is + documented in re_format(7).
+
+
Find the next tree entry which matches the current search + pattern.
+
+
Find the previous tree entry which matches the current search + pattern.
+
+

The options for tog tree are as + follows:

+
+
+ commit
+
Start traversing history at the specified + commit. The expected argument is the name of a + branch or a commit ID SHA1 hash. An abbreviated hash argument will be + expanded to a full SHA1 hash automatically, provided the abbreviation + is unique.
+
+
+
+
+
+

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

+got(1), git-repository(5), + re_format(7) +
+
+

+Stefan Sperling + <stsp@openbsd.org> +
+joshua stein + <jcs@openbsd.org> +
+
+ + + + + +
August 4, 2019OpenBSD 6.5
+ +