Re: [PATCH v4 4/7] fetch: add --refetch option

From: Robert Coup <robert@coup.net.nz>
Date: Apr 1, 2022, 10:31 UTC
Message-ID: <CACf-nVcwWCaJS7x5Qri+ZUucQKTTyL75=WscTEZkjg014+zMhw@mail.gmail.com>
In-Reply-To: <220331.86k0cap2rc.gmgdl@evledraar.gmail.com>

Hi Ævar,

On Thu, 31 Mar 2022 at 16:20, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 16 quoted lines

> > +--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@evledraar.gmail.com/
>
> 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.