commit b213cbf74334d2602c0d5f37f435603e368ff979
from: Stefan Sperling
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:
+ pack file format introduces two additional types of objects:March 6, 2020 | +March 23, 2020 | OpenBSD 6.6 |
March 6, 2020 | +March 23, 2020 | OpenBSD 6.6 |
im
import
.clone
+ [-a
] [-b
+ branch] [-l
]
+ [-m
] [-q
]
+ [-v
] [-R
+ reference] repository-URL
+ [directory]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:
+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 config file of the cloned
+ repository to store the repository-url for future
+ use by got fetch
or
+ git-fetch(1).
The options for got clone
are as
+ follows:
-a
-b
option.-b
+ branch-a
option.-l
-v
.-m
got commit
.
+ The repository's config file will
+ be set up with the “mirror” option enabled, such that
+ got fetch
or git-fetch(1)
+ will write incoming changes directly to local branches in the
+ “refs/heads/” reference namespace, rather than to
+ branches in the “refs/remotes/” namespace. This avoids
+ the usual requirement of having to run got
+ rebase
after got fetch
in order to
+ make incoming changes appear on local branches. But maintaining
+ local changes in the cloned repository becomes difficult since local
+ changes will be at risk of being discarded whenever incoming changes
+ are fetched.
-q
-v
got clone
to print
+ debugging messages to standard error output. This option will be
+ passed to ssh(1) if applicable. Multiple -v options
+ increase the verbosity. The maximum is 3.-R
+ referenceEach 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.
cl
clone
.fetch
+ [-a
] [-b
+ branch] [-d
]
+ [-l
] [-r
+ repository-path] [-t
]
+ [-q
] [-v
]
+ [-R
reference]
+ [remote-repository]got clone
.
+ New changes will be stored in a separate pack file downloaded + from the server. Optionally, separate pack files stored in the + repository can be combined with git-repack(1).
+By default, branch references in the
+ “refs/remotes/” reference namespace will be updated to
+ point at the newly fetched commits. The got
+ rebase
command can then be used to make new changes visible on
+ local branches in the “refs/heads/” namespace, merging
+ incoming changes with local changes as necessary.
If the repository was created as a mirror with
+ got clone -m
then all branches in the
+ “refs/heads/” namespace will be updated directly to match
+ the corresponding branches in the remote repository. If those branches
+ contained local commits, these commits will no longer be reachable via a
+ reference and will therefore be at risk of being discarded by Git's
+ garbage collector. Maintaining local changes in a mirror repository is
+ therefore discouraged.
In any case, references in the “refs/tags/” + namespace will always be fetched and mapped directly to local references + in the same namespace.
+The options for got fetch
are as
+ follows:
-a
-b
option.-b
+ branch-a
option.-d
-l
-v
and
+ -r
.-t
-r
+ repository-pathgot
work tree, use the
+ repository path associated with this work tree.-q
-v
got fetch
to print
+ debugging messages to standard error output. The same option will be
+ passed to ssh(1) if applicable. Multiple -v options
+ increase the verbosity. The maximum is 3.-R
+ referenceEach reference will be mapped into the local repository's
+ “refs/remotes/” namespace, unless the local repository
+ was created as a mirror with got clone -m
in
+ which case references will be mapped directly into the local
+ repository's “refs/” namespace.
Once a reference has been fetched, a local branch based on
+ it can be created with got branch
if
+ needed.
got fetch
will refuse to fetch
+ references from the remote repository's
+ “refs/remotes/” or “refs/got/”
+ namespace.
fe
fetch
.checkout
[-E
] [-b
branch] [-c
@@ -169,7 +390,7 @@
-b
+ -b
branchThe options for got update
are as
follows:
-b
+ -b
branchThe options for got log
are as
follows:
-b
-b
got log
shows
the linear history of the current branch only.-p
. By default, 3 lines of context are
shown.-l
+ -l
N-r
+ -r
repository-path-r
+ -r
repository-path-r
+ -r
repository-path-r
+ -r
repository-path-i
-R
-R
tree
.ref
[-r
repository-path]
- [-l
] [-d
- name] [-s
]
- [name target]-l
] [-c
+ object] [-s
+ reference] [-d
]
+ [name]
If no options are passed, expect two arguments and attempt to - create, or update, the reference with the given - name, and make it point at the given - target. The name must be an absolute reference - name, i.e. it must begin with “refs/”. The target may be - an object ID SHA1 hash or an existing reference which will be resolved - to an object ID. An abbreviated hash argument will be expanded to a full - SHA1 hash automatically, provided the abbreviation is unique.
+References may be listed, created, deleted, and changed. When + creating, deleting, or changing a reference the specified + name must be an absolute reference name, i.e. it + must begin with “refs/”.
The options for got ref
are as
follows:
-r
+ -r
repository-pathgot
work tree, use the
repository path associated with this work tree.-l
-d
- name-s
-l
-r
.-c
+ object-r
.-s
+ reference-r
.-d
-r
.branch
@@ -638,20 +876,20 @@
The options for got branch
are as
follows:
-c
+ -c
commit-r
+ -r
repository-pathgot
work tree, use the
repository path associated with this work tree.-l
-l
-d
+ -d
nameThe options for got tag
are as
follows:
-c
+ -c
commit-m
+ -m
message-m
option, got tag
opens a temporary file in an editor where a tag message can be
written.-r
+ -r
repository-pathgot
work tree, use the
repository path associated with this work tree.-l
-l
The options for got add
are as
follows:
-R
-R
got add
will refuse to run if a specified
path is a directory.-k
-R
-R
got remove
will refuse to run if a specified
path is a directory.-R
-R
got revert
will refuse to run if a specified
path is a directory.The options for got commit
are as
follows:
-m
+ -m
message-m
option, got
@@ -1061,10 +1299,10 @@
The options for got rebase
are as
follows:
- -a
+ -a
- Abort an interrupted rebase operation. If this option is used, no
other command-line arguments are allowed.
- -c
+ -c
- Continue an interrupted rebase operation. If this option is used, no
other command-line arguments are allowed.
@@ -1195,10 +1433,10 @@
The options for got histedit
are as
follows:
- -a
+ -a
- Abort an interrupted histedit operation. If this option is used, no
other command-line arguments are allowed.
- -c
+ -c
- Continue an interrupted histedit operation. If this option is used, no
other command-line arguments are allowed.
-F
@@ -1206,7 +1444,7 @@
- Use the specified histedit-script instead of
opening a temporary file in an editor where a histedit script can be
written.
- -m
+ -m
- Edit log messages only. This option is a quick equivalent to a
histedit script which edits only log messages but otherwise leaves
every picked commit as-is. The
-m
option can
@@ -1312,7 +1550,7 @@
The options for got stage
are as
follows:
- -l
+ -l
- Instead of staging new changes, list paths which are already staged,
along with the IDs of staged blob objects and stage status codes. If
paths were provided in the command line show the staged paths among
@@ -1425,7 +1663,7 @@
The options for got cat
are as
follows:
- -c
+ -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
@@ -1433,7 +1671,7 @@
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
+ -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
@@ -1490,10 +1728,14 @@
EXAMPLES
Clone an existing Git repository for use with
- got
. This step currently requires
- git(1):
+ got
.
$ cd /var/git/
+$ got clone
+ ssh://git@github.com/openbsd/src.git
+Use of HTTP URLs currently requires git(1):
+
+$ cd /var/git/
$ git clone --bare
https://github.com/openbsd/src.git
Alternatively, for quick and dirty local testing of
@@ -1587,12 +1829,26 @@
:-)
$ got backout
unified-buffer-cache
Fetch new upstream commits into the local repository's master - branch. This step currently requires git(1):
+Fetch new upstream commits into the local repository's + “origin/master” branch:
+$ cd /usr/src
$ got fetch
In a repository created with a HTTP URL and git
+ clone --bare
the git-fetch(1) command must be used
+ instead:
$ cd /var/git/src.git
$ git fetch origin
- master:master
Rebase the local “master” branch to merge the new + changes that are now visible on the “origin/master” + branch:
+ +$ cd /usr/src
$ got update -b
+ origin/master
$ got rebase master
Rebase the “unified-buffer-cache” branch on top of the new head commit of the “master” branch.
@@ -1612,21 +1868,47 @@ 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
+
In order to merge changes committed to the + “unified-buffer-cache” branch back into the + “master” branch, the “unified-buffer-cache” + branch must first be rebased onto the “master” branch:
+ +$ got update -b master
$ got rebase
+ unified-buffer-cache
Changes on the “unified-buffer-cache” branch can now
+ be made visible on the “master” branch with
+ got integrate
. Because the rebase operation switched
+ the work tree to the “unified-buffer-cache” branch, the work
+ tree must be switched back to the “master” branch before the
+ “unified-buffer-cache” branch can be integrated into
+ “master”:
$ got update -b master
$ got integrate
+ unified-buffer-cache
Additional steps may be necessary if local changes need to be
+ pushed back to the remote repository, which currently requires
+ git push
. 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
+ 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 +
Additionally, the “mirror” option must be + disabled:
+ +$ cd /var/git/repo
$ git config remote.origin.mirror
+ false
Alternatively, the following git-fetch(1) configuration item can be added manually to the Git repository's config file:
@@ -1634,13 +1916,15 @@url = ...
fetch =
+refs/heads/*:refs/remotes/origin/*
mirror = false
This configuration leaves the local repository's
“refs/heads” namespace free for use by local branches checked
out with got checkout
and, if needed, created with
got branch
.
Branches in the “remotes/origin” namespace can be
- updated with incoming changes from the remote repository with
- git fetch
:
Branches in the “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:
$ cd /var/git/repo
$ git fetch
$ cd /var/git/repo
$ git push origin master
In order to merge changes committed to the - “unified-buffer-cache” branch back into the - “master” branch, the “unified-buffer-cache” - branch must first be rebased onto the “master” branch:
- -$ got update -b master
$ got rebase
- unified-buffer-cache
Changes on the “unified-buffer-cache” branch can now
- be made visible on the “master” branch with
- got integrate
. Because the rebase operation switched
- the work tree to the “unified-buffer-cache” branch, the work
- tree must be switched back to the “master” branch before the
- “unified-buffer-cache” branch can be integrated into
- “master”:
$ got update -b master
$ got integrate
- unified-buffer-cache
March 6, 2020 | +March 23, 2020 | OpenBSD 6.6 |
gotweb
is
/var/www/got/public.
gotweb
should be kept
- up-to-date with a mechanism such as git-fetch(1) or
- rsync(1), scheduled by cron(8).got fetch
,
+ git-fetch(1), or rsync(1), scheduled
+ by cron(8).
March 6, 2020 | +March 23, 2020 | OpenBSD 6.6 |
March 6, 2020 | +March 23, 2020 | OpenBSD 6.6 |