Robert Coup <robert@xxxxxxxxxxx> 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?
