捆绑 git 存储库而不克隆它

Question

How can I bundle a git project without cloning it every time? Right now I do always commands below.

git clone --mirror http://git_project
cd git_project
git bundle create '../git_project.lock' --all
cd ..
rm git_project -Force -Recurse

I want to do this in one command, something like:

git bundle create '../git_project.lock' --all --repository http://git_project

Answer 1

I'll to got these bundle files as a backup on an other machine

Since my 2011 answer (eleven years ago), you now have remote pipelines like GitHub Actions or GitLab CI .

An automated pipeline on those remote Git repository hosting services can create a bundle for you and save it to a server/backup.

That is today.

---

Tomorrow, you will be able to a " git bundle "-dedicated server, accessible through a bundle URI .

With Git 2.38 (Q3 2022), the "bundle URI" design gets documented.

See commit d06ed85 , commit 2da14fa (09 Aug 2022) by Derrick Stolee ( derrickstolee ) .
^{(Merged by Junio C Hamano -- gitster -- in commit 0d133a3 , 18 Aug 2022)}

docs : document bundle URI standard

^{Signed-off-by: Derrick Stolee}

Introduce the idea of bundle URIs to the Git codebase through an aspirational design document.
This document includes the full design intended to include the feature in its fully-implemented form.
This will take several steps as detailed in the Implementation Plan section.

By committing this document now, it can be used to motivate changes necessary to reach these final goals.
The design can still be altered as new information is discovered.

technical/bundle-uri now includes in its man page :

Bundle URIs

Git bundles are files that store a pack-file along with some extra metadata, including a set of refs and a (possibly empty) set of necessary commits. See git bundle and link:bundle-format.txt[the bundle format] for more information.

Bundle URIs are locations where Git can download one or more bundles in order to bootstrap the object database in advance of fetching the remaining objects from a remote.

One goal is to speed up clones and fetches for users with poor network connectivity to the origin server. Another benefit is to allow heavy users, such as CI build farms, to use local resources for the majority of Git data and thereby reducing the load on the origin server.

To enable the bundle URI feature, users can specify a bundle URI using command-line options or the origin server can advertise one or more URIs via a protocol v2 capability.

See Also

• An earlier RFC for a bundle URI feature .

• The GVFS Protocol

And:

bundle-uri : add example bundle organization

^{Signed-off-by: Derrick Stolee}

Add a section that details how a bundle provider could work, including using the Git server advertisement for multiple geo-distributed servers.
This organization is based on the GVFS Cache Servers which have successfully used similar ideas to provide fast object access and reduced server load for very large repositories.

technical/bundle-uri now includes in its man page :

Example Bundle Provider organization

This example organization is a simplified model of what is used by the GVFS Cache Servers (see section near the end of this document) which have been beneficial in speeding up clones and fetches for very large repositories, although using extra software outside of Git.

The bundle provider deploys servers across multiple geographies.
Each server manages its own bundle set.

The server can track a number of Git repositories, but provides a bundle list for each based on a pattern.

For example, when mirroring a repository at https://<domain>/<org>/<repo> the bundle server could have its bundle list available at https://<server-url>/<domain>/<org>/<repo> .
The origin Git server can list all of these servers under the "any" mode:

 [bundle] version = 1 mode = any [bundle "eastus"] uri = https://eastus.example.com/<domain>/<org>/<repo> [bundle "europe"] uri = https://europe.example.com/<domain>/<org>/<repo> [bundle "apac"] uri = https://apac.example.com/<domain>/<org>/<repo>

This "list of lists" is static and only changes if a bundle server is added or removed.

The bundle server runs regularly-scheduled updates for the bundle list, such as once a day.
During this task, the server fetches the latest contents from the origin server and generates a bundle containing the objects reachable from the latest origin refs, but not contained in a previously-computed bundle.
This bundle is added to the list, with care that the creationToken is strictly greater than the previous maximum creationToken .

An example bundle list is provided here, although it only has two daily bundles and not a full list of 30:

 [bundle] version = 1 mode = all heuristic = creationToken [bundle "2022-02-13-1644770820-daily"] uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644770820-daily.bundle creationToken = 1644770820 [bundle "2022-02-09-1644442601-daily"] uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644442601-daily.bundle creationToken = 1644442601 [bundle "2022-02-02-1643842562"] uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-02-1643842562.bundle creationToken = 1643842562

The intention of this data organization has two main goals.

• First, initial clones of the repository become faster by downloading precomputed object data from a closer source.

• Second, git fetch commands can be faster, especially if the client has not fetched for a few days. However, if a client does not fetch for 30 days, then the bundle list organization would cause redownloading a large amount of object data.