On 3/9/2022 1:32 PM, Junio C Hamano wrote: > - we must maintain the "filter that is consistent with the contents > of this repository", which this series does not do, but we should. If this is possible/reasonably implementable then... > - 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. ... this is the logical conclusion that can be drawn. > isn't "git fetch --filter" 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? There are two cases to be considered here: 1. The user changes the filter config using "git config" 2. The user runs "git fetch --filter" The first case is the use case advocated by Robert for "--refetch". I originally suggested saving the last used filter into the config and if the last used filter != the configured filter, then fetch automatically "refetches" everything. The second use case is the one Junio believes I am referring to, however, whether to classify this as a bug or feature, I am uncertain. Like above, I suggested saving this as the last used filter to be used as a comparison to the configured filter. Setting this filter as the configured filter can be a separate discussion to be had because I can see pros/cons for it. Ultimately the expectation is that if I run "git fetch" without --filter, then I will fetch based on the config filter. And if I have previously run "git fetch" with the same filter, whether through the config or my own filter, then Git will only fetch the latest refs/objects. On Wed, Mar 9, 2022 at 1:32 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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?
