Christian Couder <christian.couder@xxxxxxxxx> 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.
