On Wed, Sep 4, 2024 at 9:59 PM Shubham Kanodia <shubhamsizzles@xxxxxxxxx> wrote: > > On Tue, Sep 3, 2024 at 9:37 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Patrick Steinhardt <ps@xxxxxx> writes: > > > > > The prefetch refspec would be rewritten by git-maintenance(1) such that > > > the destination part (the right-hand side of the refspec) is prefixed > > > with `refs/prefetch/`, same as the fetch refspec would be changed in > > > this way. > > > > > > An alternative would be to _not_ rewrite the prefetch refspec at all and > > > thus allow the user to prefetch into arbitrary hierarchies. But I'm a > > > bit worried that this might cause users to misconfigure prefetches by > > > accident, causing it to overwrite their usual set of refs. > > > > I agree that it is the right place to configure this as attributes > > to remotes. It would make it handy if we could give a catch-all > > configuration, though. For example: > > > > [remote "origin"] > > prefetch = true > > prefetchref = refs/heads/* refs/tags/* > > [remote "*"] > > prefetch = false > > > > may toggle prefetch off for all remotes, except that the tags and > > the local branches of the remote "origin" are prefetched. Instead > > of a multi-value configuration variable (like remote.*.fetch) where > > we need to worry about clearing convention, we can use a regular > > "last one wins" variable that is whitespace separated patterns, as > > such a pattern can never have a whitespace in it. > > > > As you too agree with the position to consider "prefetch" should be > > invisible to the end-users, we should not allow users to specify the > > full refspec at all, or if it is forced or not with "+" prefix. > > Only accept a set of patterns to match, and keep it opaque where in > > the local refs/* hierarchy they are stored. It is an implementation > > detail that the users should not have to know about and rely on. > > > > Thanks. > > Right so I have good direction to start working on this. I'm going to > tackle this in a few parts since this is my first contribution — > > 1. adding a boolean `prefetch` attribute to `remote` — allows control > over remotes that prefetch > 2. adding `prefetchref` — allows control over refs per remote. > 3. Check if adding a ` [remote "*"]` catchall is a possibility > > For the boolean `prefetch` value the — > 1. The default would be assumed to be `true` > 2. No changes in behavior to any variation of `git fetch --prefetch` > command itself. > If no remote is supplied to `git fetch` then it means default remote, > or if `--all` is used, it means all remotes and `--prefetch` for both > always > prefetches irrespective of the config value. > > If I understand the codebase well, the changes would primarily affect > `remote.c` and `gc.c`. > > Also much thanks for the feedback both of you've given thus far. I've published my first patch using gitgitgadget. I'm still figuring out what the best way to link to that is but I'll add both for now: https://lore.kernel.org/git/pull.1779.git.1725472799637.gitgitgadget@xxxxxxxxx/T/#u https://github.com/gitgitgadget/git/pull/1779 -- Regards, Shubham Kanodia
