Skip to content

Commit 1d9c8da

Browse files
avargitster
authored andcommitted
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 <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 0bb92f3 commit 1d9c8da

File tree

1 file changed

+7
-7
lines changed

1 file changed

+7
-7
lines changed

Documentation/git-bundle.txt

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -147,13 +147,13 @@ SPECIFYING REFERENCES
147147
Revisions must accompanied by reference names to be packaged in a
148148
bundle.
149149

150-
More than one reference may be packaged, and more than one basis can
150+
More than one reference may be packaged, and more than one set of prerequisite objects can
151151
be specified. The objects packaged are those not contained in the
152-
union of the given bases.
152+
union of the prerequisites.
153153

154154
The 'git bundle create' command resolves the reference names for you
155155
using the same rules as `git rev-parse --abbrev-ref=loose`. Each
156-
basis can be specified explicitly (e.g. `^master~10`), or implicitly
156+
prerequisite can be specified explicitly (e.g. `^master~10`), or implicitly
157157
(e.g. `master~10..master`, `--since=10.days.ago master`).
158158

159159
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.).
236236
We want to update R2 with development made on the branch master in R1.
237237

238238
To bootstrap the process, you can first create a bundle that does not have
239-
any basis. You can use a tag to remember up to what commit you last
239+
any prerequisites. You can use a tag to remember up to what commit you last
240240
processed, in order to make it easy to later update the other repository
241241
with an incremental bundle:
242242

@@ -287,7 +287,7 @@ machineB$ git pull
287287

288288
If you know up to what commit the intended recipient repository should
289289
have the necessary objects, you can use that knowledge to specify the
290-
basis, giving a cut-off point to limit the revisions and objects that go
290+
prerequisites, giving a cut-off point to limit the revisions and objects that go
291291
in the resulting bundle. The previous example used the lastR2bundle tag
292292
for this purpose, but you can use any other options that you would give to
293293
the linkgit:git-log[1] command. Here are more examples:
@@ -298,7 +298,7 @@ You can use a tag that is present in both:
298298
$ git bundle create mybundle v1.0.0..master
299299
----------------
300300

301-
You can use a basis based on time:
301+
You can use a prerequisite based on time:
302302

303303
----------------
304304
$ git bundle create mybundle --since=10.days master
@@ -311,7 +311,7 @@ $ git bundle create mybundle -10 master
311311
----------------
312312

313313
You can run `git-bundle verify` to see if you can extract from a bundle
314-
that was created with a basis:
314+
that was created with a prerequisite:
315315

316316
----------------
317317
$ git bundle verify mybundle

0 commit comments

Comments
 (0)