> Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > > > As part of this, index-pack has to output (1) the hash that goes into > > the name of the .pack/.idx file and (2) the hashes of all dangling > > .gitmodules. I just had (2) come after (1). If anyone has a better idea, > > I'm interested. > > I have this feeling that the "blobs that need to be validated across > packs" will *not* be the last enhancement we'd need to make to the > output from index-pack to allow richer communication between it and > its invoker. While there is no reason to change how the first line > of the output looks like, we'd probably want to make sure that the > future versions of Git can easily tell "list of blobs that require > further validation" from other additional information. > > I am not comfortable to recommend "ok, then let's add a delimiter > line '---\n' if/when we need to have something after the list of > blobs and append more stuff in future versions of Git", because we > may find need to emit new kinds of info before the list of blobs > that needs further validation, for example, in future versions of > Git. > > Having said all that, the internal communication between the > index-pack and its caller do not need as much care about > compatibility across versions as output visible to end-users, so > when a future version of Git needs to send different kinds of > information in different order from what you created here, we can do > so pretty much freely, I would guess. Yeah, that's what I thought too - since this is an internal interface, we can evolve them in lockstep. If we're really worried about the Git binaries (on a user's system) getting out of sync, we could just make sure that subsequent updates to this protocol are non-backwards-compatible (e.g. have index-pack emit "foo <hash>", where "foo" is a string that describes the new check, so that current fetch-pack will reject "foo" since it is not a hash).
