Robert Coup <robert@xxxxxxxxxxx> 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.
