mirror of
https://github.com/git/git
synced 2024-08-27 19:49:21 +00:00
bundle doc: replace "basis" with "prerequsite(s)"
In the preceding commits we introduced new documentation that talks about "[commit|object] prerequsite(s)", but also faithfully moved around existing documentation that talks about the "basis". Let's change both that moved-around documentation and other existing documentation in the file to consistently use "[commit|object]" prerequisite(s)" instead of talking about "basis". The mention of "basis" isn't wrong, but readers will be helped by us using only one term throughout the document for this concept. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
0bb92f3a3a
commit
1d9c8daef8
|
@ -147,13 +147,13 @@ SPECIFYING REFERENCES
|
|||
Revisions must accompanied by reference names to be packaged in a
|
||||
bundle.
|
||||
|
||||
More than one reference may be packaged, and more than one basis can
|
||||
More than one reference may be packaged, and more than one set of prerequisite objects can
|
||||
be specified. The objects packaged are those not contained in the
|
||||
union of the given bases.
|
||||
union of the prerequisites.
|
||||
|
||||
The 'git bundle create' command resolves the reference names for you
|
||||
using the same rules as `git rev-parse --abbrev-ref=loose`. Each
|
||||
basis can be specified explicitly (e.g. `^master~10`), or implicitly
|
||||
prerequisite can be specified explicitly (e.g. `^master~10`), or implicitly
|
||||
(e.g. `master~10..master`, `--since=10.days.ago master`).
|
||||
|
||||
All of these simple cases are OK (assuming we have a "master" and
|
||||
|
@ -236,7 +236,7 @@ but we can move data from A to B via some mechanism (CD, email, etc.).
|
|||
We want to update R2 with development made on the branch master in R1.
|
||||
|
||||
To bootstrap the process, you can first create a bundle that does not have
|
||||
any basis. You can use a tag to remember up to what commit you last
|
||||
any prerequisites. You can use a tag to remember up to what commit you last
|
||||
processed, in order to make it easy to later update the other repository
|
||||
with an incremental bundle:
|
||||
|
||||
|
@ -287,7 +287,7 @@ machineB$ git pull
|
|||
|
||||
If you know up to what commit the intended recipient repository should
|
||||
have the necessary objects, you can use that knowledge to specify the
|
||||
basis, giving a cut-off point to limit the revisions and objects that go
|
||||
prerequisites, giving a cut-off point to limit the revisions and objects that go
|
||||
in the resulting bundle. The previous example used the lastR2bundle tag
|
||||
for this purpose, but you can use any other options that you would give to
|
||||
the linkgit:git-log[1] command. Here are more examples:
|
||||
|
@ -298,7 +298,7 @@ You can use a tag that is present in both:
|
|||
$ git bundle create mybundle v1.0.0..master
|
||||
----------------
|
||||
|
||||
You can use a basis based on time:
|
||||
You can use a prerequisite based on time:
|
||||
|
||||
----------------
|
||||
$ git bundle create mybundle --since=10.days master
|
||||
|
@ -311,7 +311,7 @@ $ git bundle create mybundle -10 master
|
|||
----------------
|
||||
|
||||
You can run `git-bundle verify` to see if you can extract from a bundle
|
||||
that was created with a basis:
|
||||
that was created with a prerequisite:
|
||||
|
||||
----------------
|
||||
$ git bundle verify mybundle
|
||||
|
|
Loading…
Reference in a new issue