Re: [PATCH v2 3/3] fetch: use bundle URIs when having creationToken heuristic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux