On 11/3/2017 11:05 AM, Junio C Hamano wrote:
Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes:
Yes, I thought we should have both (perhaps renamed or combined
into 1 parameter with value, such as --exclude=missing vs --exclude=promisor)
and let the user decide how strict they want to be.
Assuming we eventually get promisor support working, would there be
any use case where "any missing is OK" mode would be useful in a
sense more reasonable than "because we could have such a mode" and
"it is not our business to prevent users from playing with fire"?
For now, I'd like to keep my "any missing is OK" option.
I do think it has value all by itself.
We are essentially using something like that now with our GVFS
users on the gigantic Windows repo and haven't had any issues.
But yes, when we get promisor support working, we could revisit
the need for this parameter.
However, I do have some scaling concerns here. If for example,
I have 100M missing blobs (because we did an only commits-and-trees
clone), the cost to compute "promisor missing" vs "just missing"
might be prohibitively expensive. It could be something we want
fsck/gc to be aware of, but other commands may want to just assume
any missing objects are expected and continue.
Hopefully, we won't have a scale problem, but we just don't know
yet.
Jeff
