Toon Claes <toon@xxxxxxxxx> writes: > At the moment, bundle URIs are only used by git-clone(1). For a clone > the use of bundle URI is trivial, because the repository is empty so > downloading bundles will never result in downloading objects that are in > the repository already. > > For git-fetch(1), this more complicated to use bundle URI. We want to Nit: s/this/it is/ > avoid downloading bundles that only contains objects that are in the > local repository already. > > One way to achieve this is possible when the "creationToken" heuristic > is used for bundle URIs. We attempt to download and unbundle the minimum This first sentence reads a bit weird. Perhaps, "One way to achieve this is to restrict the usage of bundle URIs to the 'creationToken' heuristic for git-fetch(1)."? > number of bundles by creationToken in decreasing order. If we fail to > unbundle (after a successful download) then move to the next > non-downloaded bundle and attempt downloading. Once we succeed in > applying a bundle, move to the previous unapplied bundle and attempt to > unbundle it again. At the end the highest applied creationToken is > written to `fetch.bundleCreationToken` in the git-config. The next time > bundles are advertised by the server, bundles with a lower creationToken > value are ignored. This was already implemented by > 7903efb717 (bundle-uri: download in creationToken order, 2023-01-31) in > fetch_bundles_by_token(). > > Using the creationToken heuristic is optional, but without it the client > has no idea which bundles are new, how to sort them, and which only have > objects the client already has. > > With this knowledge, make git-fetch(1) use bundle URIs from the server, > but only when the creationToken heuristic is used. > I would say that apart from all this it is also worth noting that bundle URIs are still opt-in from the client side. Rest of the patch looks good to me. Thanks [snip]
Attachment:
signature.asc
Description: PGP signature
