Re: [PATCH 6/9] repack: add `--filter=<filter-spec>` option

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> writes:

>> I may be missing something, but to me, the above sound more like a
>> tail wagging the dog.
> ...
> This might be a good idea, but what if users prefer to send to a
> promisor remote the objects that should be on that promisor remote as
> soon as possible, instead of keeping them on the local machine where
> they take up possibly valuable space for no good reason?
> ...
> There are some configurations where users never want to delete any git
> object. In those cases it doesn't matter if the promisor remote is a
> "dumping ground".

When one says "everything" in these sentences, I doubt one
necessarily means "everything".  A topic one works on will have
iterations that is never pushed out, a topic one started may not
even get to the state that is pushable to the central server.  But
the objects that need to support such a topic (and its historical
versions in its reflog) would need to be retained until they are
expired.

Certainly, by pushing even such objects, you can say "here is a pack
with filter=blob:none, and because I sent every blob every time I
create locally to the promisor, I can always refetch what is not in
them by definition".

But is that a good use of everybody's resources?  The key phrase in
what I said was "... and still leve the resulting promisor usable".

The promisor remote is in the unfortunate and unenviable position
that it cannot garbage collect anything because there may be
somebody who is still depending on such an object nobody planned to
use, but there is no mechanism to let it find out which ones are in
active use (or if you added some recently that I am forgetting, it
would change the equation---please remind me if that is the case).

So I would imagine that it would be fairly high in the priority list
of server operators and project leads to make sure their promisor
remotes do not become a true "dumping ground".

For "trim a bloated lazy clone" problem, I suspect that you would
need to know what is currently re-fetchable from the promisor and
drop those objects from your local repository, and the computation
of what is currently re-fetchable would certainly involve the filter
specification you had with the promisor.  The remote-tracking
branches you have for the promisor would serve as the other source
of input to perform the computation.

For "partition local and complete object store" problem, using
filter specification to sift the objects into two bins (those that
match and the rest), as the code changes in the series implements,
may be a useful mechansim.  I briefly had to wonder if partitioning
into two (and not arbitrary number N) bins is sufficient, but did
not think of a scenario where we would benefit from 3 bins more than
having 2 bins offhand.

Thanks.