Derrick Stolee <stolee@xxxxxxxxx> writes:
> The other issue is that exact matches (no "*") have an exact
> string in the destination, too, so replacing the _entire_
> destination with "refs/prefetch/<remote>/*" breaks the refspec.
> I think the substring approach will still work here.
I wonder if that matters. If the exact format says
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git/
fetch = +refs/heads/todo:refs/x/y/z
you can just add refs/prefetch/<remote>/ to the entire RHS to ensure
that (1) the prefetch would not affect anything outside the 'prefetch'
to break @{upstream} and friends, and (2) the prefetch from this remote
would not affect anything used for other remotes.
IOW, the RHS, as long as it is hidden from normal operations and
does not conflict with interaction with other repositories, where
exactly in the refs hierarchy these objects are "parked" does not
matter, I would think.
I do not recommend unparsed refspec and textually munging, by the
way. Doesn't
git fetch master:remotes/origin/master
first parse to normalize the src/dst sides to turn it into
git fetch refs/heads/master:refs/remotes/origin/master
which is what you want to further redirect to the prefetch hierarchy
git fetch +refs/heads/master:refs/prefetch/origin/refs/remotes/origin/master
or whatever munging scheme is used?
Also, I wonder if there should be a mechanism to prune the
prefetched refs, but that is totally outside the scope of the
problem we have been discussing in this thread.
