Masaya Suzuki <masayasuzuki@xxxxxxxxxx> 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 > (https://tools.ietf.org/html/rfc5234#appendix-B.1), 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"). Thanks.
