|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
Hey Mark,
I've been working with Dave on this issue so I can expand on some of the details. I'll note that my information is still second hand, as I've received this information from someone else, but that someone works on git, so, I'm satisfied with the answer. Here's hoping I'm repeating the information again correctly![]()
.
When you use git clone, you receive cryptographic/verifiable assurance that the server has provided you all the objects. When you run 'git clone', the directory is set up, the server collects all the objects, the transfer happens. After it's complete, the receiving end runs a quick verification on the packfile(s), and then puts all the objects in place on the local filesystem, and the process is done.
This is as opposed to git fetch, which is meant for incremental updates. After a fetch completes, git walks the object graph; In most cases this is merely from your previous head forward through all of the new objects, verifying that everything is intact. In Dave's case, walking the entire history of the repository accounts for the vast majority of the execution time. Longer than the default fetch timeout of 10 minutes, for the record.
Receiving data itself isn't any faster, but the verification that takes place after receiving objects via fetch is dramatically different.