On 6/8/2022 3:46 PM, Derrick Stolee wrote: > On 6/6/2022 8:33 PM, Junio C Hamano wrote: >> "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: I'm finally getting around to applying the recommended changes locally, when I noticed... >>> + present in the client repository. If some are missing, then the client >>> + delays unbundling until other bundles have been unbundled, making those >>> + OIDs present. When all required OIDs are present, the client unbundles >>> + that data using a refspec. The default refspec is >>> + `+refs/heads/*:refs/bundles/*`, but this can be configured. >> >> The refs/bundles/ appear in the document only here, and it is >> unclear why we even want it (I am assuming this is against gc while >> "git clone" is still running) or how we are going to retire it, if >> ever. If there are multiple bundle files involved in this "git clone", >> to anchor objects that are necessary against "gc", don't we need to use >> refs/bundles/<i>/* or something like that, where <i> is uniquely assigned >> number locally? > > The real reason to keep them in refs/bundles/ is because then those > refs can be used in the incremental 'git fetch' after downloading the > bundles (in perpetuity) while not stomping refs/heads or refs/remotes/ ...I completely ignored your "refs/bundles/<i>/*" suggestion, which is an interesting way to allow dropping refs from this space, allowing GC to clear up space over time. I'm making note of this and will include it as a potential way forward (while I also think about what the implementation would look like). Thanks, -Stolee
