On Thu, Apr 08 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> On Wed, Apr 07 2021, Derrick Stolee wrote: >> >>> The purpose is to allow us to modify a 'struct refspec_item' >>> andproduce a refspec string instead of munging a refspec string >>> directly. > > Ouch. I thought the goal was to take > > [remote "origin"] > fetch = $src:$dst > > let the code that is used in the actual fetching to parse it into > the in-core "refspec_item", and then transform the refspec_item by > > - discarding it if the item does not result in storing in the real > fetch > > - tweaking $dst side so that it won't touch anywhere outside > refs/prefetch/ to avoid disturbing end-user's notion of what the > latest state of the remote ref is. > > so that the "parsed" refspec_item is passed to the fetch machinery > without ever having to be converted back to textual form. > > Why do we even need to "andproduce a refspec string"? We're shelling out to "git fetch", but we first munge the refspec on in "git gc". But yes, it seems even more straightforward to do away with passing the refspec at all to "git fetch", and instead pass some (maybe internal only, and documented as such) "--refspec-dst-prefix=refs/prefetch/" option to "git fetch". I.e. get_ref_map() over there is already doing a version of this loop over "remote->fetch.nr". So instead of "git gc" doing the loop, then passing all the refspecs on the command-line, it could tell "git fetch" to do the same munging when it does the same iteration. Doing the munging in builtin/gc.c's fetch_remote() just seems like a relic from when we didn't care what decision builtin/fetch.c made about refspecs, we always wanted our custom one.
