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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Mar 31, 2022, 15:18 UTC
Message-ID: <220331.86k0cap2rc.gmgdl@evledraar.gmail.com>
In-Reply-To: <78501bbf28105ef252976266abb437a278585609.1648476132.git.gitgitgadget@gmail.com>

On Mon, Mar 28 2022, Robert Coup via GitGitGadget wrote:

Show 15 quoted lines

> From: Robert Coup <robert@coup.net.nz>
>
> Teach fetch and transports the --refetch option to force a full fetch
> without negotiating common commits with the remote. Use when applying a
> new partial clone filter to refetch all matching objects.
>
> [...]
> +ifndef::git-pull[]
> +--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.
> +endif::git-pull[]

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?

Show 10 quoted lines

>  		return -1;
>  
> +	/*
> +	 * Similarly, if we need to refetch, we always want to perform a full
> +	 * fetch ignoring existing objects.
> +	 */
> +	if (refetch)
> +		return -1;
> +
> +

One too many \n here.