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.
