mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Masaya Suzuki <>
Cc: Git Mailing List <>
Subject: Re: [PATCH] doc: describe Git bundle format
Date: Fri, 31 Jan 2020 15:01:07 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Masaya Suzuki's message of "Fri, 31 Jan 2020 13:49:53 -0800")

Masaya Suzuki <> writes:

>> > +prerequisite = "-" obj-id SP comment LF
>> > +comment      = *CHAR
>> Do readers know what CHAR consists of?  Anything other than NUL and
>> LF?
> RFC 5234 defines core rules
> (, and these CHAR etc
> are defined there. It should be OK to use these rules.

That's not what I asked.  Do readers know that?  Did you tell them
that we expect they are familiar with the RFC convention?

It might be easier to make the above simple ABNF understandable to
those without knowledge of RFC 5234 by spelling out what CHAR in the
context of the above description means.  Or to tell them "go over
there and learn CHAR then come back".  We need to do one of them.

> I want to make sure the meaning of prerequisites.
> 1. Are they meant for a delta base? Or are they meant to represent a
> partial/shallow state?

They are meant as the "bottom boundary" of the range of the pack
data stored in the bundle.

Think of "git rev-list --objects $heads --not $prerequisites".  If
we limit ourselves to commits, in the simplest case, "git log
maint..master".  Imagine your repository has everything up to
'maint' (and nothing else) and then you are "git fetch"-ing from
another repository that advanced the tip that now points at
'master'.  Imagine the data transferred over the network.  Imagine
that data is frozen on disk somehow.  That is what a bundle is.

So, 'maint' is the prerequisite---for the person who builds the
bundle, it can safely be assumed that the bundle will be used only
by those who already has 'maint'.

There is nothing about 'partial' or 'shallow'.  And even though a
bundle typically has deltified objects in the packfile, it does not
have to.  Some objects are delitifed against prerequisite, and the
logic to generate thin packs may even prefer to use the
prerequisites as the delta base, but it is merely a side effect that
the prerequisites are at the "bottom boundary" of the range.

> 2. Do they need to be commits? Or can they be any object type?
> From what I can see, it seems that they should always be commits.
> 3. Does the receiver have to have all reachable objects from prerequisites?

I would say that the receiver needs to have everything that is
needed to "complete" prereqs.

Bundle transfer predates shallow or incomplete repositories, but I
think that we can (and we should if needed) update it to adjust to
these situations by using the appropriate definition of what it
means to "complete".  In a lazy clone, it may be sufficient to have
promisor remote that has everything reachable from them.  In a
shallow clone, the repository may have to be deep enough to have
them and objects immediately reachable from them (e.g. trees and
blobs for a commit at the "bottom boundary").


  reply	other threads:[~2020-01-31 23:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 22:58 [PATCH] doc: describe Git bundle format Masaya Suzuki
2020-01-31 13:56 ` Johannes Schindelin
2020-01-31 20:38 ` Junio C Hamano
2020-01-31 21:49   ` Masaya Suzuki
2020-01-31 23:01     ` Junio C Hamano [this message]
2020-01-31 23:57       ` Masaya Suzuki
2020-02-04 18:20         ` Junio C Hamano
2020-01-31 22:18 ` [PATCH v2] " Masaya Suzuki
2020-01-31 23:06   ` Junio C Hamano
2020-02-07 20:42   ` [PATCH v3] " Masaya Suzuki
2020-02-07 20:44     ` Masaya Suzuki
2020-02-07 20:59       ` Junio C Hamano
2020-02-07 22:21         ` Masaya Suzuki
2020-02-08  1:49           ` Junio C Hamano
2020-02-12 22:13             ` Masaya Suzuki
2020-02-12 22:43               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).