Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> Split out the discussion bout "object prerequisites" into its own
> section, and add some more examples of the common cases.
>
> See 2e0afafebd (Add git-bundle: move objects and references by
> archive, 2007-02-22) for the introduction of the documentation being
> changed here.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> ---
> Documentation/git-bundle.txt | 26 +++++++++++++++++++++++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
> index 9c743aed49f..f5430029b8c 100644
> --- a/Documentation/git-bundle.txt
> +++ b/Documentation/git-bundle.txt
> @@ -45,6 +45,7 @@ header is (mostly) in the format emitted by linkgit:git-show-ref[1].
>
> Like the the packed archive format itself bundles can either be
> self-contained, or be created using exclusions.
> +See the "OBJECT PREREQUISITES" section below.
>
> Bundles created using revision exclusions are "thin packs" created
> using the `--thin` option to linkgit:git-pack-objects[1], and
> @@ -153,19 +154,38 @@ contained in the union of the given bases. Each basis can be
> specified explicitly (e.g. `^master~10`), or implicitly (e.g.
> `master~10..master`, `--since=10.days.ago master`).
>
> -It is very important that the basis used be held by the destination.
> +OBJECT PREREQUISITES
> +--------------------
> +
> +When creating bundles it is possible to create a fully self-contained
> +bundle with all the prerequisite objects, as well as providing
> +negative revisions to exclude prerequisite objects.
> +
> +A revision such as `new` will produce a tip with all the prerequisite
> +objects needed for the `new` reference.
The above two paragraphs use the word "prerequisites" in a confusing
way. The original meaning of the word in the context of talking
about a bundle is "you must have these commits in the receiving
repository for the bundle to be unbundle-able".
"git bundle create recent.bndl old..new" creates a bundle that
requires 'old' (and everything reachable from it) to exist in the
receiving repository. We call the object 'old' (not the objects
reachable from it) the prerequisite of the bundle.
"git bundle create full.bndl new" creates a bundle that needs no
prerequistes.
It is confusing to say that full.bndl has all the prerequisite
objects needed. It is correct to say that it has all the objects
reachable from 'new', but if we wanted to say that, we did not have
to introduce the new term "prerequisite" when we invented the bundle
format. The concept "prerequisite" tries to convey is different.
So, the two paragraphs above use the word "prerequisite" when it
wants to talk about "reachable objects" (except for one use---the
one in "to exclude prerequisite objects" is correctly used), which
is confusing. Here is the first paragraph with probably a better
phrasing.
... it is possible to create a self-contained bundle that
can be unbundled in an empty repository, as well as
providing negative revisions to exclude objects needed in
the earlier parts of the history.
As to the second paragraph:
... will produce a bundle without any prerequisites. It can
be unbundled in any repository to obtain a full history that
leads to the commit `new`.
By the way, I needed to read "a revision such as `new` will produce
..." three times before realizing that the reader must fill quite a
lot of missing words to understand what the sentence wanted to say,
which is:
(feeding) a revision such as `new` (to "git bundle create"
as the revision range argument) will produce ...
I think it is easier to follow if you spelled the command out, e.g.
A command
$ git bundle create full.bndl new
will create a bundle file that contains all the objects
reachable from the branch 'new'.
> +A revision range such as `old..new` will produce a bundle tip that'll
> +require any objects existing before `new` to already be present in the
> +repository performing the 'git bundle unbundle' operation.
Getting warmer ;-). In this case, 'old' is the prerequisite, so
... that'll require the commit 'old' (and any objects reachable
from it) to exist for the bundle to be "unbundle"-able.
would be correct.
> +A self-contained bundle without any prerequisites can be extracted
> +into anywhere, even into an empty repository, or be cloned from
> +(i.e., `new`, but not `old..new`).
> +
This is entirely correct.
> +The 'git bundle verify' command can be used to check whether your
> +recipient repository has the required prerequisite commits for a
> +bundle.
So is this.
Thanks.
