On 6/21/2022 4:16 PM, Junio C Hamano wrote: > Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: > >>>> 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. > > FWIW, I wasn't thinking about GC and expiration. If bundle URI > thing can say "you need this, that and that other bundle" and cause > you to fetch three bundles, I thought that there needs a way for you > to record the tips of these three bundles---these three bundles > should not have to compete for refs/bundles/master, for example. Not wanting to compete makes sense, but also we should usually expect the "most recent" bundle to be the most recent version of the branch. However, that ordering only makes sense when we have the creationToken (nee timestamp) heuristic, so having distinct ref spaces makes sense to avoid collisions. Thanks, -Stolee
