Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: >> Then get_pack() can move a lot of code out of it to this helper and >> just call it. The processing the other packfile obtained by the >> packfile URI mechanism out of band can open the packstream and call >> the helper the same way. When packfile URI mechanism is in use, both >> invocations of the helper would get "you are not alone so fsck may >> hit missing objects" bit, if fsck-objects are asked for. >> >> That would avoid the "duplicated logic" and still allow the code to >> choose the best disposition of the incoming packdata per packfile. >> >> In an extreme case, it is not hard to imagine that somebody prepares >> a very small base packfile and feed it via packfile URI mechanism, >> but have accumulated so many objects that are not yet rolled into an >> updated base packfile---cloning from such a repository may result in >> running unpack-objects for the packfile that came out of band, while >> processing the in-stream packfile with index-pack. >> >> Hmm? > > Your suggestion (as opposed to the current situation, in which we're > locked into using index-pack for the out-of-band packfiles) would make > this possible, yes. Just to make sure, I am not interested in running unpack-objects on oob packfiles, as they are expected to be "so old, big and not changing that it is worth pre-generating" packfiles, so "yes the approach would make that useless thing possible" is not a useful criteria to judge how good the alternative approach would be. If the approach results in a cleaner design that gives us more flexibility without risking unnecessary code duplication, it would be a good sign that the approach is more sound than the direction we took so far, though. Thanks.
