Taylor Blau <me@xxxxxxxxxxxx> writes: > Teach pack-objects an option to imply the revision machinery's new > '--no-kept-objects' option when doing a reachability traversal. > > When '--assume-kept-packs-closed' is given as an argument to > pack-objects, it behaves differently (i.e., passes different options to > the ensuing revision walk) depending on whether or not other arguments > are passed: > > - If the caller also specifies a '--keep-pack' argument (to mark a > pack as kept in-core), then assume that this combination means to > stop traversal only at in-core packs. > > - If instead the caller passes '--honor-pack-keep', then assume that > the caller wants to stop traversal only at packs with a > corresponding .keep file (consistent with the original meaning which > only refers to packs with a .keep file). > > - If both '--keep-pack' and '--honor-pack-keep' are passed, then > assume the caller wants to stop traversal at either kind of kept > pack. If there is an out-of-band guarantee that .kept packs won't refer to outside world, then we can obtain identical results to what existing --honor-pack-keep (which traverses everything and then filteres out what is in .keep pack) does by just stopping traversal when we see an object that is found in a .keep pack. OK, I guess that it answers the correctness question I asked about [02/10]. It still is curious how we can safely "assume", but presumably we will see how in a patch that appears later in the series. How "closed" are these kept packs supposed to be? When there are two .keep packs, should objects in each of the packs never refer to outside their own pack, or is it OK for objects in one kept pack to refer to another object in the other kept pack? Readers and those who want to understand and extend this code in the future would need to know what definition of "closed" you are using here. Thanks.
