Re: git gc does not discard objects found in alternate unless the?alternate storage is packed

sergio [off-list ref] wrote:

Shawn O. Pearce <spearce <at> spearce.org> writes:

quoted

Sergio <sergio.callegari <at> gmail.com> wrote:

quoted

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.