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>
maint
Nanako Shiraishi16 years agocommitted byJunio C Hamano
@ -84,7 +84,7 @@ defining the basis. More than one reference may be packaged, and more
@@ -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.
@@ -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
------------
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:
- Using a tag present in both repositories
------------------------
[remote "origin"]
url = /home/me/tmp/file.bdl
fetch = refs/heads/*:refs/remotes/origin/*
------------------------
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.
After working more in the original repository, you can create an