mirror of
https://github.com/git/git
synced 2024-08-27 11:39:22 +00:00
git-bundle doc: update examples
This rewrites the example part of the bundle doucmentation to follow the suggestion made by Junio during a recent discussion (gmane 108030). Instead of just showing different ways to create and use bundles in a disconnected fashion, the rewritten example first shows the simplest "full cycle" of sneakernet workflow, and then introduces various variations. The words are mostly taken from Junio's outline. I only reformatted them and proofread to make sure the end result flows naturally. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
34263de026
commit
8aa7eebfb3
|
@ -84,7 +84,7 @@ defining the basis. More than one reference may be packaged, and more
|
|||
than one basis can be specified. The objects packaged are those not
|
||||
contained in the union of the given bases. Each basis can be
|
||||
specified explicitly (e.g., ^master~10), or implicitly (e.g.,
|
||||
master~10..master, master --since=10.days.ago).
|
||||
master~10..master, --since=10.days.ago master).
|
||||
|
||||
It is very important that the basis used be held by the destination.
|
||||
It is okay to err on the side of conservatism, causing the bundle file
|
||||
|
@ -94,75 +94,111 @@ when unpacking at the destination.
|
|||
EXAMPLE
|
||||
-------
|
||||
|
||||
Assume two repositories exist as R1 on machine A, and R2 on machine B.
|
||||
Assume you want to transfer the history from a repository R1 on machine A
|
||||
to another repository R2 on machine B.
|
||||
For whatever reason, direct connection between A and B is not allowed,
|
||||
but we can move data from A to B via some mechanism (CD, email, etc).
|
||||
We want to update R2 with developments made on branch master in R1.
|
||||
|
||||
To create the bundle you have to specify the basis. You have some options:
|
||||
To bootstrap the process, you can first create a bundle that doesn't have
|
||||
any basis. You can use a tag to remember up to what commit you sent out
|
||||
in order to make it easy to later update the other repository with
|
||||
incremental bundle,
|
||||
|
||||
- Without basis.
|
||||
+
|
||||
This is useful when sending the whole history.
|
||||
----------------
|
||||
machineA$ cd R1
|
||||
machineA$ git bundle create file.bdl master
|
||||
machineA$ git tag -f lastR2bundle master
|
||||
----------------
|
||||
|
||||
------------
|
||||
$ git bundle create mybundle master
|
||||
------------
|
||||
Then you sneakernet file.bdl to the target machine B. Because you don't
|
||||
have to have any object to extract objects from such a bundle, not only
|
||||
you can fetch/pull from a bundle, you can clone from it as if it was a
|
||||
remote repository.
|
||||
|
||||
- Using temporally tags.
|
||||
+
|
||||
We set a tag in R1 (lastR2bundle) after the previous such transport,
|
||||
and move it afterwards to help build the bundle.
|
||||
----------------
|
||||
machineB$ git clone /home/me/tmp/file.bdl R2
|
||||
----------------
|
||||
|
||||
------------
|
||||
$ git bundle create mybundle master ^lastR2bundle
|
||||
$ git tag -f lastR2bundle master
|
||||
------------
|
||||
|
||||
- Using a tag present in both repositories
|
||||
|
||||
------------
|
||||
$ git bundle create mybundle master ^v1.0.0
|
||||
------------
|
||||
|
||||
- A basis based on time.
|
||||
|
||||
------------
|
||||
$ git bundle create mybundle master --since=10.days.ago
|
||||
------------
|
||||
|
||||
- With a limit on the number of commits
|
||||
|
||||
------------
|
||||
$ git bundle create mybundle master -n 10
|
||||
------------
|
||||
|
||||
Then you move mybundle from A to B, and in R2 on B:
|
||||
|
||||
------------
|
||||
$ git bundle verify mybundle
|
||||
$ git fetch mybundle master:localRef
|
||||
------------
|
||||
|
||||
With something like this in the config in R2:
|
||||
This will define a remote called "origin" in the resulting repository that
|
||||
lets you fetch and pull from the bundle. $GIT_DIR/config file in R2 may
|
||||
have an entry like this:
|
||||
|
||||
------------------------
|
||||
[remote "bundle"]
|
||||
[remote "origin"]
|
||||
url = /home/me/tmp/file.bdl
|
||||
fetch = refs/heads/*:refs/remotes/origin/*
|
||||
------------------------
|
||||
|
||||
You can first sneakernet the bundle file to ~/tmp/file.bdl and
|
||||
then these commands on machine B:
|
||||
You can fetch/pull to update the resulting mine.git repository after
|
||||
replacing the bundle you store at /home/me/tmp/file.bdl with incremental
|
||||
updates from here on.
|
||||
|
||||
------------
|
||||
$ git ls-remote bundle
|
||||
$ git fetch bundle
|
||||
$ git pull bundle
|
||||
------------
|
||||
After working more in the original repository, you can create an
|
||||
incremental bundle to update the other:
|
||||
|
||||
would treat it as if it is talking with a remote side over the
|
||||
network.
|
||||
----------------
|
||||
machineA$ cd R1
|
||||
machineA$ git bundle create file.bdl lastR2bundle..master
|
||||
machineA$ git tag -f lastR2bundle master
|
||||
----------------
|
||||
|
||||
and sneakernet it to the other machine to replace /home/me/tmp/file.bdl,
|
||||
and pull from it.
|
||||
|
||||
----------------
|
||||
machineB$ cd R2
|
||||
machineB$ git pull
|
||||
----------------
|
||||
|
||||
If you know up to what commit the intended recipient repository should
|
||||
have the necessary objects for, you can use that knowledge to specify the
|
||||
basis, giving a cut-off point to limit the revisions and objects that go
|
||||
in the resulting bundle. The previous example used lastR2bundle tag
|
||||
for this purpose, but you can use other options you would give to
|
||||
the linkgit:git-log[1] command. Here are more examples:
|
||||
|
||||
You can use a tag that is present in both.
|
||||
|
||||
----------------
|
||||
$ git bundle create mybundle v1.0.0..master
|
||||
----------------
|
||||
|
||||
You can use a basis based on time.
|
||||
|
||||
----------------
|
||||
$ git bundle create mybundle --since=10.days master
|
||||
----------------
|
||||
|
||||
Or you can use the number of commits.
|
||||
|
||||
----------------
|
||||
$ git bundle create mybundle -10 master
|
||||
----------------
|
||||
|
||||
You can run `git-bundle verify` to see if you can extract from a bundle
|
||||
that was created with a basis.
|
||||
|
||||
----------------
|
||||
$ git bundle verify mybundle
|
||||
----------------
|
||||
|
||||
This will list what commits you must have in order to extract from the
|
||||
bundle and will error out if you don't have them.
|
||||
|
||||
A bundle from a recipient repository's point of view is just like a
|
||||
regular repository it fetches/pulls from. You can for example map
|
||||
refs, like this example, when fetching:
|
||||
|
||||
----------------
|
||||
$ git fetch mybundle master:localRef
|
||||
----------------
|
||||
|
||||
Or see what refs it offers.
|
||||
|
||||
----------------
|
||||
$ git ls-remote mybundle
|
||||
----------------
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
Loading…
Reference in a new issue