git-bundle(1)

From 6ac2f147aa1e6774a32f6ed56a833ef7f08f9871 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 1 Mar 2007 01:24:56 +0000 Subject: [PATCH] Autogenerated HTML docs for v1.5.0.2-260-g2eb065 --- RelNotes-1.5.0.3.txt | 55 ++++++ RelNotes-1.5.1.txt | 65 ++++++- cmds-mainporcelain.txt | 3 + git-bundle.html | 430 +++++++++++++++++++++++++++++++++++++++++ git-bundle.txt | 139 +++++++++++++ git-remote.html | 25 ++- git-remote.txt | 17 +- git-rev-parse.html | 12 +- git-rev-parse.txt | 7 + git.html | 10 +- 10 files changed, 754 insertions(+), 9 deletions(-) create mode 100644 RelNotes-1.5.0.3.txt create mode 100644 git-bundle.html create mode 100644 git-bundle.txt diff --git a/RelNotes-1.5.0.3.txt b/RelNotes-1.5.0.3.txt new file mode 100644 index 000000000..90b49cf27 --- /dev/null +++ b/RelNotes-1.5.0.3.txt @@ -0,0 +1,55 @@ +GIT v1.5.0.2 Release Notes +========================== + +Fixes since v1.5.0.2 +-------------------- + +* Bugfixes + + - 'git.el' honors the commit coding system from the configuration. + + - 'blameview' in contrib/ correctly digs deeper when a line is + clicked. + + - 'http-push' correctly makes sure the remote side has leading + path. Earlier it started in the middle of the path, and + incorrectly. + + - 'cvsexportcommit' does not lose yet-to-be-used message file. + + - int-vs-size_t typefix when running combined diff on files + over 2GB long. + + - 'git apply --whitespace=strip' should not touch unmodified + lines. + + - 'git-mailinfo' choke when a logical header line was too long. + + - 'git show A..B' did not error out. Negative ref ("not A" in + this example) does not make sense for the purpose of the + command, so now it errors out. + + - 'git fmt-merge-msg --file' without file parameter did not + correctly error out. + + - 'git archimport' barfed upon encountering a commit without + summary. + + - 'git index-pack' did not protect itself from getting a short + read out of pread(2). + +* Documentation updates + + - options to 'git remote add' were described insufficiently. + + +--- +exec >/var/tmp/1 +O=v1.5.0.2 +O=v1.5.0.2-16-gdb554bf +echo O=`git describe maint` +git shortlog --no-merges $O..maint + +# Local Variables: +# mode: text +# End: diff --git a/RelNotes-1.5.1.txt b/RelNotes-1.5.1.txt index 4d371866c..5ce385b44 100644 --- a/RelNotes-1.5.1.txt +++ b/RelNotes-1.5.1.txt @@ -19,17 +19,76 @@ Updates since v1.5.0 - "git diff" learned --ignore-space-at-eol. This is a weaker form of --ignore-space-change. + - "git diff --no-index pathA pathB" can be used as diff + replacement with git specific enhancements. + - "git name-rev" learned --refs=, to limit the tags used for naming the given revisions only to the ones matching the given pattern. + - "git remote update" is to run "git fetch" for defined remotes + to update tracking branches. + + - "git cvsimport" can now take '-d' to talk with a CVS + repository different from what are recorded in CVS/Root + (overriding it with environment CVSROOT does not work). + + - "git bundle" can help sneaker-netting your changes between + repositories. + + * Updated behaviour of existing commands. + - git-svn got almost a rewrite. + + - core.autocrlf configuration, when set to 'true', makes git + to convert CRLF at the end of lines in text files to LF when + reading from the filesystem, and convert in reverse when + writing to the filesystem. The variable can be set to + 'input', in which case the conversion happens only while + reading from the filesystem but files are written out with + LF at the end of lines. Currently, which paths to consider + 'text' (i.e. be subjected to the autocrlf mechanism) is + decided purely based on the contents, but the plan is to + allow users to explicitly override this heuristics based on + paths. + + - The behaviour of 'git-apply', when run in a subdirectory, + without --index nor --cached were inconsistent with that of + the command with these options. This was fixed to match the + behaviour with --index. A patch that is meant to be applied + with -p1 from the toplevel of the project tree can be + applied with any custom -p option. A patch that is not + relative to the toplevel needs to be applied with -p + option with or without --index (or --cached). + - "git diff" outputs a trailing HT when pathnames have embedded SP on +++/--- header lines, in order to help "GNU patch" to parse its output. "git apply" was already updated to accept this modified output format since ce74618d (Sep 22, 2006). + - "git cvsserver" runs hooks/update and honors its exit status. + + - "git cvsserver" can be told to send everything with -kb. + + - "git diff --check" also honors the --color output option. + + - "git name-rev" used to stress the fact that a ref is a tag too + much, by saying something like "v1.2.3^0~22". It now says + "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does + not talk about an ancestor of the commit that is tagged, which + makes sense). + + - "git rev-list --boundary" now shows boundary markers for the + commits omitted by --max-age and --max-count condition. + + - The configuration mechanism now reads $(prefix)/etc/gitconfig. + + - "git apply --verbose" shows what preimage lines were wanted + when it couldn't find them. + + - "git status" in a read-only repository got a bit saner. + * Hooks - The sample update hook to show how to send out notification @@ -39,6 +98,10 @@ Updates since v1.5.0 -- exec >/var/tmp/1 -O=v1.5.0-49-g69bc0e2 +O=v1.5.0.2-259-g16d5315 echo O=`git describe master` git shortlog --no-merges $O..master ^maint + +# Local Variables: +# mode: text +# End: diff --git a/cmds-mainporcelain.txt b/cmds-mainporcelain.txt index 49922e672..f01571b71 100644 --- a/cmds-mainporcelain.txt +++ b/cmds-mainporcelain.txt @@ -13,6 +13,9 @@ gitlink:git-bisect[1]:: gitlink:git-branch[1]:: List, create, or delete branches. +gitlink:git-bundle[1]:: + Move objects and refs by archive. + gitlink:git-checkout[1]:: Checkout and switch to a branch. diff --git a/git-bundle.html b/git-bundle.html new file mode 100644 index 000000000..c413dd129 --- /dev/null +++ b/git-bundle.html @@ -0,0 +1,430 @@ + + + + + + +git-bundle(1) + + + +

SYNOPSIS

git-bundle create <file> [git-rev-list args] +git-bundle verify <file> +git-bundle list-heads <file> [refname…] +git-bundle unbundle <file> [refname…]

DESCRIPTION

Some workflows require that one or more branches of development on one +machine be replicated on another machine, but the two machines cannot +be directly connected so the interactive git protocols (git, ssh, +rsync, http) cannot be used. This command provides suport for +git-fetch and git-pull to operate by packaging objects and references +in an archive at the originating machine, then importing those into +another repository using git-fetch(1) and git-pull(1) +after moving the archive by some means (i.e., by sneakernet). As no +direct connection between repositories exists, the user must specify a +basis for the bundle that is held by the destination repository: the +bundle assumes that all objects in the basis are already in the +destination repository.

OPTIONS

+create <file> +: +
+ Used to create a bundle named file. This requires the + git-rev-list arguments to define the bundle contents. +
+
+verify <file> +: +
+ Used to check that a bundle file is valid and will apply + cleanly to the current repository. This includes checks on the + bundle format itself as well as checking that the prerequisite + commits exist and are fully linked in the current repository. + git-bundle prints a list of missing commits, if any, and exits + with non-zero status. +
+
+list-heads <file> +: +
+ Lists the references defined in the bundle. If followed by a + list of references, only references matching those given are + printed out. +
+
+unbundle <file> +: +
+ Passes the objects in the bundle to git-index-pack(1) + for storage in the repository, then prints the names of all + defined references. If a reflist is given, only references + matching those in the given list are printed. This command is + really plumbing, intended to be called only by + git-fetch(1). +
+
+[git-rev-list-args…] +: +
+ A list of arguments, accepatble to git-rev-parse and + git-rev-list, that specify the specific objects and references + to transport. For example, "master~10..master" causes the + current master reference to be packaged along with all objects + added since its 10th ancestor commit. There is no explicit + limit to the number of references and objects that may be + packaged. +
+
+[refname…] +: +
+ A list of references used to limit the references reported as + available. This is principally of use to git-fetch, which + expects to recieve only those references asked for and not + necessarily everything in the pack (in this case, git-bundle is + acting like git-fetch-pack(1)). +
+

SPECIFYING REFERENCES

git-bundle will only package references that are shown by +git-show-ref: this includes heads, tags, and remote heads. References +such as master~1 cannot be packaged, but are perfectly suitable for +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).

It is very important that the basis used be held by the destination. +It is ok to err on the side of conservatism, causing the bundle file +to contain objects already in the destination as these are ignored +when unpacking at the destination.

EXAMPLE

Assume two repositories exist as R1 on machine A, and 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. +We set a tag in R1 (lastR2bundle) after the previous such transport, +and move it afterwards to help build the bundle.

in R1 on A: +$ git-bundle create mybundle master ^lastR2bundle +$ git tag -f lastR2bundle master

(move mybundle from A to B by some mechanism)

in R2 on B: +$ git-bundle verify mybundle +$ git-fetch mybundle refspec

where refspec is refInBundle:localRef

Also, with something like this in your config:

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:

$ git ls-remote bundle +$ git fetch bundle +$ git pull bundle

would treat it as if it is talking with a remote side over the +network.

Author

Written by Mark Levedahl <mdl123@verizon.net>

GIT

Part of the git(7) suite

+ + + diff --git a/git-bundle.txt b/git-bundle.txt new file mode 100644 index 000000000..4ea9e85d5 --- /dev/null +++ b/git-bundle.txt @@ -0,0 +1,139 @@ +git-bundle(1) +============= + +NAME +---- +git-bundle - Move objects and refs by archive + + +SYNOPSIS +-------- +'git-bundle' create [git-rev-list args] +'git-bundle' verify +'git-bundle' list-heads [refname...] +'git-bundle' unbundle [refname...] + +DESCRIPTION +----------- + +Some workflows require that one or more branches of development on one +machine be replicated on another machine, but the two machines cannot +be directly connected so the interactive git protocols (git, ssh, +rsync, http) cannot be used. This command provides suport for +git-fetch and git-pull to operate by packaging objects and references +in an archive at the originating machine, then importing those into +another repository using gitlink:git-fetch[1] and gitlink:git-pull[1] +after moving the archive by some means (i.e., by sneakernet). As no +direct connection between repositories exists, the user must specify a +basis for the bundle that is held by the destination repository: the +bundle assumes that all objects in the basis are already in the +destination repository. + +OPTIONS +------- + +create :: + Used to create a bundle named 'file'. This requires the + git-rev-list arguments to define the bundle contents. + +verify :: + Used to check that a bundle file is valid and will apply + cleanly to the current repository. This includes checks on the + bundle format itself as well as checking that the prerequisite + commits exist and are fully linked in the current repository. + git-bundle prints a list of missing commits, if any, and exits + with non-zero status. + +list-heads :: + Lists the references defined in the bundle. If followed by a + list of references, only references matching those given are + printed out. + +unbundle :: + Passes the objects in the bundle to gitlink:git-index-pack[1] + for storage in the repository, then prints the names of all + defined references. If a reflist is given, only references + matching those in the given list are printed. This command is + really plumbing, intended to be called only by + gitlink:git-fetch[1]. + +[git-rev-list-args...]:: + A list of arguments, accepatble to git-rev-parse and + git-rev-list, that specify the specific objects and references + to transport. For example, "master~10..master" causes the + current master reference to be packaged along with all objects + added since its 10th ancestor commit. There is no explicit + limit to the number of references and objects that may be + packaged. + + +[refname...]:: + A list of references used to limit the references reported as + available. This is principally of use to git-fetch, which + expects to recieve only those references asked for and not + necessarily everything in the pack (in this case, git-bundle is + acting like gitlink:git-fetch-pack[1]). + +SPECIFYING REFERENCES +--------------------- + +git-bundle will only package references that are shown by +git-show-ref: this includes heads, tags, and remote heads. References +such as master~1 cannot be packaged, but are perfectly suitable for +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). + +It is very important that the basis used be held by the destination. +It is ok to err on the side of conservatism, causing the bundle file +to contain objects already in the destination as these are ignored +when unpacking at the destination. + +EXAMPLE +------- + +Assume two repositories exist as R1 on machine A, and 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. +We set a tag in R1 (lastR2bundle) after the previous such transport, +and move it afterwards to help build the bundle. + +in R1 on A: +$ git-bundle create mybundle master ^lastR2bundle +$ git tag -f lastR2bundle master + +(move mybundle from A to B by some mechanism) + +in R2 on B: +$ git-bundle verify mybundle +$ git-fetch mybundle refspec + +where refspec is refInBundle:localRef + + +Also, with something like this in your config: + +[remote "bundle"] + 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: + +$ git ls-remote bundle +$ git fetch bundle +$ git pull bundle + +would treat it as if it is talking with a remote side over the +network. + +Author +------ +Written by Mark Levedahl + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/git-remote.html b/git-remote.html index ae6be1373..ad4330507 100644 --- a/git-remote.html +++ b/git-remote.html @@ -274,7 +274,7 @@ git-remote(1) Manual Page

git-remote -git-remote add <name> <url> +git-remote add [-t <branch>] [-m <branch>] [-f] <name> <url> git-remote show <name> git-remote prune <name> git-remote update [group]

@@ -350,7 +350,11 @@ be updated. (See git-config(1)).

Examples

Add a new remote, fetch, and check out a branch from it:

+Add a new remote, fetch, and check out a branch from it +

$ git remote
@@ -370,6 +374,21 @@ linux-nfs/master
 $ git checkout -b nfs linux-nfs/master
 ...

+Imitate git clone but track only selected branches +

$ mkdir project.git
+$ cd project.git
+$ git init
+$ git remote add -f -t master -m master origin git://example.com/git.git/
+$ git merge origin

+git-bundle(1) Manual Page +

NAME