Hi Ævar, On Thu, 31 Mar 2022 at 16:20, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > +--refetch:: > > + Instead of negotiating with the server to avoid transferring commits and > > + associated objects that are already present locally, this option fetches > > + all objects as a fresh clone would. Use this to reapply a partial clone > > + filter from configuration or using `--filter=` when the filter > > + definition has changed. > > Re my comment on negotiation specifics in 2/7, this documentation is > really over-promising depending on what the answer to that is: > https://lore.kernel.org/git/220331.86o81mp2w1.gmgdl@xxxxxxxxxxxxxxxxxxx/ > > I.e. instead of saying that we WILL fetch all objects "just like a > clone" shouldn't we have less focus on implementation details here, and > assure the user that we'll make their object store "complete" as though > --filter hadn't been used, without going into the specifics of what'll > happen over the wire? That's not quite the case though: we'll make their object db complete as if a fresh clone with any specified --filter (including none) from that remote has been done. IMO explaining what will happen and to expect (particularly as this is _not_ transferring some sort of object-delta-set, clone transfers can be big) is a good thing. If it improves later; then change the docs. Alternatively, rewording along the lines of "it will fix up your object db to match a changed filter" is implying that only the missing bits will be fetched. Thanks, Rob.
