On Sat, Apr 10, 2021 at 06:35:40PM -0700, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > * The fix is almost completely rewritten as an update to 'git fetch'. See > > the new PATCH 2 for this update. > > I do agree that it gives us the most flexibility there with nice > encapsulation. Nobody other than "git fetch" needs to know how it > computes which remote refs are fetched given the real pathspec, and > the only thing the caller with "--prefetch" is interested in is that > the prefetch operation would not contaminate the remote-tracking > refs. > > Great idea. I wish I were the one who thought of it first ;-) Yes - this simplifies things greatly! I do have one case that fails prefetch though. It's a case where all the remote's fetch configs are filtered out. Example: [remote "pr-924"] url = https://github.com/gitgitgadget/git fetch = +refs/tags/pr-924/derrickstolee/maintenance/refspec-v3 skipfetchall = true tagopt = --no-tags In this case, running `git fetch pr-924` will fetch and update FETCH_HEAD, but running with maintenance prefetch task results in: fatal: Couldn't find remote ref HEAD error: failed to prefetch remotes error: task 'prefetch' failed I tracked this down a bit, but don't have a suggestion how to fix it. builtin/fetch.c `get_ref_map` makes two calls to `filter_prefetch_refspec`, one for 'rs' and another for 'remote->fetch'. `filter_prefetch_refspec` works and filters out the above fetch config. This correctly yields condition `rs->nr == 0` and `remote->fetch.nr == 0` Later a call is made to `get_remote_ref(remote_refs, "HEAD")` which fails, leading to `fatal: Couldn't find remote ref HEAD` Should this be expected, or should this now be special-cased for 'prefetch' somehow? Regards, --Tom
