Re: [PATCH v5 2/3] bundle doc: elaborate on object prerequisites

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 2, 2021, 15:10 UTC
Message-ID: <xmqq7di8rbtj.fsf@gitster.g>
In-Reply-To: <patch-2.3-444b06740bc-20210702T112254Z-avarab@gmail.com>

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

Show 38 quoted lines

> 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@gmail.com>
> ---
>  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.