Re: [PATCH v2 0/8] fetch: add repair: full refetch without negotiation

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

Robert Coup <robert@coup.net.nz> writes:

> fleshen-partial sounds like a horror movie scene to me.
>
> 1. `--refetch`

I do think, as part of a larger "repair" task, fetching objects
again from a known-good remote would be a sensible one step.  So
"re"fetch would be a good way to phrase it.

> 2. `--as-clone`

This I think is in the same vein.

> 3. `--expand-filter` (though TBC you don't necessarily need a filter)
> 4. `--refilter`

These focus on a wrong thing, I would think.  "I suspect my object
store may be missing some objects, and I want to repair it by
getting another copy from a known-good remote" would be the simplest
and easiest-to-explain form of the end-user requirement this feature
helps.  The end-user wish does not require "filter" at all.

But this reminds of me about a few caveats.

The patch does implement a good way to lie about what we have to the
other end, forcing them to send everything that is necessary to
create a new clone.

But that is only a half of what is required to "repair a possibly
broken object store by re-fetching".  It is sufficient for repairing
"missing objects", but not enough for repairing "broken/corrupt"
objects.  The object store has a mechanism to resist collision
attacks by ignoring objects coming over the network that do not
match what we locally already have.

I offhand do not think it is a practical problem that this new
mechanism is incapable of repair a repository with broken/corrupt
objects [*].  But tying the bland and broad word "repair" to the
feature that is meant to only deal with "missing" but not "curropt"
form of object store breakage may lead to confusion.

	Side note: others who spent more time on partial/lazy clone
	might realize that broken/corrupt objects are real problems
	they want to tackle, though.  I dunno, and that is why I am
	raising it as a potential issue.

Thanks.