Re: git clone: very long "resolving deltas" phase
- From
Nicolas Pitre <nico@fluxnic.net>
- Date
- Apr 7, 2010, 14:40 UTC
- Message-ID
- <alpine.LFD.2.00.1004071022140.7232@xanadu.home>
- In-Reply-To
- <loom.20100407T112028-388@post.gmane.org>
On Wed, 7 Apr 2010, Marat Radchenko wrote:
Show 6 quoted lines
> Nicolas Pitre <nico <at> fluxnic.net> writes: > > The "Resolving deltas" is performed locally, when Git is actually > > expanding all the deltas in the received pack to find the actual SHA1 of > > the resulting object in order to create the pack index. > Is there any technical limitation why it cannot be done simultaniously with > fetch (piped or whatever), instead of a separate step after fetch?
The non delta compressed objects are indexed simultaneously as they're received on the wire. However this is way suboptimal to do that for delta objects because
1) The base object needed to resolve a given delta object might not have been received yet. This means in this case that the delta will have to be resolved later anyway, and finding out if a just received object might be a base object for previously received objects is rather costly, and even impossible if that potential base object is itself a delta. So it is best to figure out the delta dependencies only once at the end of the transfer.
2) When resolving deep delta chains, it is best to start from the root i.e. create the result from a delta object and resolve all deltas with this result for base recursively, not to expand deltas repeatedly which would turn this process into exponential CPU usage. Again this can be done only when all delta objects have been received.
Nicolas