On 6/9/2022 1:56 PM, Junio C Hamano wrote: > Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: > >> Ævar's observation that bundles also add ref tips to the packfile is >> the key to breaking down this concern: these ref tips give us a way >> to negotiate the difference between what the client already has >> (including the bundles downloaded from a bundle provider) and what it >> wants from the origin Git server. This all happens without any change >> necessary to the origin Git server. >> >> And thus, this bundle URI design came about. It takes all of the best >> things about the GVFS Cache Server but then layers refs on top of the >> time-based prefetch packfiles so a normal Git client can do that >> "catch-up fetch" afterwards. > > Yup. My observation was that (1) you would need ref tips in some > way, (2) you are conveying not just "here are the set of bundle > files", but "this bundle file has these associated attributes" (like > .timestamp, and .uri to fetch it from), in the table-of-contents the > clients are expected to obtain anyway, hence (3) you could, but you > do not need to, use bundle as a way to convey "packfile contents > plus refs" to the clients (iow, instead you can use packfile and > then report these refs information in the table-of-contents as more > "associated attributes" to the items listed in the table-of-contents). ... > Starting from "bundle URI standard" document at the beginning of the > thread, if we replace all the mentions of "bundle file" with > "packfile" in it, and then add .positiveRefs and .negativeRefs to > each "packfile" (renamed from "bundle file") as additional > "packfile.<id>.*" (renamed from "bundle.<id>.*") attributes, without > changing anything else, the result would be feature equivalent to > the original "bundle URI standard", I would think, but without > having to wrap a packfile in a bundle file? > >> I hope I am going in the right direction here, but I likely >> misunderstood some of your proposed alternatives. > > I wasn't seriously "proposing" an alternative. It was just that it > looked wasteful to go to a separate format (i.e. bundle) when packfiles > should suffice, as you would be adding extra information that is not > in bundles via the table-of-contents anyway, and what is given by a > bundle that is missing in a packfile is only the refs information, > which should be trivial to add to the table-of-contents. Ok, I've trimmed your latest reply to focus on the main point: "Why bundles?" You are right that we could use a table of contents to list the metadata that we need (that is currently stored in the bundle header) except for one case: the single bundle. If the provider wants to skip the table of contents/bundle list and only provide one file that bootstraps clones, then we need something more than just a packfile. This could be remedied by _requiring_ the table of contents with the ref list, but it does lead to separation of the packfile from the important ref information. Further, the provider might want to cover a large number of refs, not just the default ref. That would increase the size of the table of contents more than necessary. With these things in mind, I do still think bundles are a good way to store and share this data. Thanks, -Stolee
