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.
