sergio <sergio.callegari@xxxxxxxxx> wrote: > Shawn O. Pearce <spearce <at> spearce.org> writes: > > Sergio <sergio.callegari <at> gmail.com> wrote: > > > > > > Is it the intended behaviour? > > > > This is the current (intended) behavior. We have never pruned an > > object from a repository unless the object is packed in the shared > > alternate repository. See git-prune-packed's man page. The prune > > logic for loose objects only deletes objects which are in packs, > > and it doesn't care where that pack came from. > > Many thanks for the explanation. > Two more questions: > 1) Is there a way to prune objects that are anyway available at the alternate > without touching the alternate (to repack it)? No, no such function exists today in Git. Why? Because nobody has coded it. We needed git-prune-packed for local repository usage once git-repack has finished its main work of running pack-objects to produce a new pack file. This extended nicely into also pruning loose objects which are also available from a shared database, as the code was actually identical. > 2) Would there be any contraindication in doing so? (namely, is the current > behaviour of git gc a mere consequence of the prune-packed logic or a behaviour > purposely introduced for safety?) Well, yes and no. The first part of the answer is that yes, one could delete the object from the clone if it is available loose in the alternate. The object can still be read through the alternate, so there is no data loss, and thus it really is just a matter of someone writing the necessary code to implement this prune function. The second part of the answer is that no, doing this deletion may make it less safe to use the alternate as an alternate. The reason is that objects which are contained in pack files are likely to be reachable in the alternate, and thus won't disappear during a later git-prune invocation, as they are needed by that alternate. This assumption is based upon the fact that an object only goes into a pack file if it is reachable in that repository, as the packing code uses reachability to determine what to pack. Relying upon a loose object may cause breakage later on if the alternate doesn't actually need that object and prunes it away, and the clone doesn't have it either. However, this pack based assumption can fail anyway if the alternate repository rewinds a branch and repacks. The object you were relying on in the alternate may now be ejected into a loose object, or discarded altogether, and the clone will (eventually) break anyway when the object(s) it needs goes missing. So it is sort-of a safety measure, but its a crude one at best. And it only works about some X% of the time, where X is well under 100. :-) -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
