diff options
Diffstat (limited to 'content/git-bundle-hosting.rst')
| -rw-r--r-- | content/git-bundle-hosting.rst | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/content/git-bundle-hosting.rst b/content/git-bundle-hosting.rst index 7505836..2431c46 100644 --- a/content/git-bundle-hosting.rst +++ b/content/git-bundle-hosting.rst @@ -6,7 +6,7 @@ :status: published :summary: Cloning large repositories can result in quite some load on the server side. A possible solution is the use of bundles. Git can package a certain revision in an archive. The client can fetch the bundle and set up a clone locally based on the bundle. -Cloning large repositories can result in quite some load on the server side. Depending on the server specs, the server may run out of RAM or the CPU load goes way up. In my case, the limiting factor is the CPU. Too much load can even result in fatal errors that make it impossible to freshly clone a repository. +Cloning large repositories can result in quite some load on the server side. Depending on the server specs, the server may run out of RAM or the CPU load increases heavily. In my case, the limiting factor is the CPU. Too much load can even result in fatal errors that make it impossible to freshly clone a repository. A possible solution is the use of bundles. Git can package a certain revision in an archive. The client can fetch the bundle and set up a clone locally based on the bundle. The `Git documentation <https://git-scm.com/docs/git-bundle>`_ describes how this works. The server then has the only task of serving the bundle which takes almost no load. When the client has set up the clone with the bundle, subsequent pull or fetch requests will take a lot less server load because the server only needs to handle the diff between the revision archived in the bundle and the revision that currently gets fetched. |