Subject: Re: [PATCH v3 0/7] fetch: add repair: full refetch without negotiation

From: Junio C Hamano <[email-masked]>
Date: Wed, 09 Mar 2022 13:32:42 -0800

Robert Coup <[email-masked]> writes:

> So, if you do a partial clone using `git clone --filter=...` then the
> filter is saved into the config at `remote.<name>.partialclonefilter`
> and is re-used by default for subsequent fetches from that remote. But
> there's nothing to stop `git fetch --filter=...` being run multiple
> times with different filters to carefully setup a repository for a
> particular use case, or any notion that there has to be "one" filter
> in place for a remote.

The way I read Calvin's suggestion was that you won't allow such a
random series of "git fetch"es without updating the "this is the
filter that is consistent with the contents of this repository"
record, which will lead to inconsistencies.  I.e.

 - we must maintain the "filter that is consistent with the contents
   of this repository", which this series does not do, but we should.

 - the "--refetch" is unnecessary and redundant, as long as such a
   record is maintained; when a filter settings changes, we should
   do the equivalent of "--refetch" automatically.

IOW, ...

> Running `git fetch --filter=...` doesn't update the remote's partial
> clone filter in the config, and IMO it shouldn't for the above reason.

... isn't "git fetch --fitler" that does not update the configured
filter (and does not do a refetch automatically) a bug that made the
"refetch" necessary in the first place?

Or perhaps I read Calvin incorrectly?