Hi Jonathan, On Wed, 2 Feb 2022 at 19:00, Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote: > > Thanks - I think this is a useful feature. This is useful even in a > non-partial-clone repo, to repair objects that were, say, accidentally > deleted from the local object store. I'd > If it's acceptable to have a separate command to configure the new > filter in the repo config (or to delete it, if we want to convert a > partial clone into a regular repo), I think it's clearer to name this > option "--repair" or something like that, and explain it as a fetch that > does not take into account the contents of the local object store (not > as a fetch that changes the filter). I quite like --repair, since the implementation really has zero to do with filtering or partial clones beyond that being my use case for it. Specifying a filter, shallow options, or even using a promisor remote aren't even slightly necessary for the implementation as it turns out. And as you say, that makes it easier to explain too: "fetch --repair will fetch all objects from the remote (applying any filters or shallow options as requested). Unlike a normal fetch it does not take into account any content already in the local repository and acts more like an initial clone. Any duplicate objects will get cleaned up during subsequent maintenance." "If you want to update your local repository with a different partial clone filter, use `fetch --repair` to re-download all matching objects from the remote." > I'll try > to review the implementation by the end of this week (but other reviews > are welcome too, needless to say). Thanks! Rob :)
