+++ /dev/null
-git-clone-pack(1)
-=================
-
-NAME
-----
-git-clone-pack - Clones a repository by receiving packed objects
-
-
-SYNOPSIS
---------
-'git-clone-pack' [--exec=<git-upload-pack>] [<host>:]<directory> [<head>...]
-
-DESCRIPTION
------------
-Clones a repository into the current repository by invoking
-'git-upload-pack', possibly on the remote host via ssh, in
-the named repository, and stores the sent pack in the local
-repository.
-
-OPTIONS
--------
---exec=<git-upload-pack>::
- Use this to specify the path to 'git-upload-pack' on the
- remote side, if it is not found on your $PATH.
- Installations of sshd ignore the user's environment
- setup scripts for login shells (e.g. .bash_profile) and
- your privately installed git may not be found on the system
- default $PATH. Another workaround suggested is to set
- up your $PATH in ".bashrc", but this flag is for people
- who do not want to pay the overhead for non-interactive
- shells by having a lean .bashrc file (they set most of
- the things up in .bash_profile).
-
-<host>::
- A remote host that houses the repository. When this
- part is specified, 'git-upload-pack' is invoked via
- ssh.
-
-<directory>::
- The repository to sync from.
-
-<head>...::
- The heads to update. This is relative to $GIT_DIR
- (e.g. "HEAD", "refs/heads/master"). When unspecified,
- all heads are updated to match the remote repository.
-+
-Usually all the refs from existing repository are stored
-under the same name in the new repository. Giving explicit
-<head> arguments instead writes the object names and refs to
-the standard output, just like get-fetch-pack does.
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano.
-
-
-GIT
----
-Part of the gitlink:git[7] suite
-
<dd>\r
<p>\r
Operate quietly. This flag is passed to "rsync" and\r
- "git-clone-pack" commands when given.\r
+ "git-fetch-pack" commands when given.\r
</p>\r
</dd>\r
<dt>\r
<dd>\r
<p>\r
When given, and the repository to clone from is handled\r
- by <em>git-clone-pack</em>, <em>--exec=<upload-pack></em> is passed to\r
+ by <em>git-fetch-pack</em>, <em>--exec=<upload-pack></em> is passed to\r
the command to specify non-default path for the command\r
run on the other end.\r
</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-Jun-2006 09:29:19 UTC\r
+Last updated 22-Jun-2006 19:49:24 UTC\r
</div>\r
</div>\r
</body>\r
--quiet::
-q::
Operate quietly. This flag is passed to "rsync" and
- "git-clone-pack" commands when given.
+ "git-fetch-pack" commands when given.
-n::
No checkout of HEAD is performed after the clone is complete.
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is handled
- by 'git-clone-pack', '--exec=<upload-pack>' is passed to
+ by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
the command to specify non-default path for the command
run on the other end.
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-rebase</em> [--onto <newbase>] <upstream> [<branch>]</p>\r
+<p><em>git-rebase</em> [--merge] [--onto <newbase>] <upstream> [<branch>]</p>\r
<p><em>git-rebase</em> --continue | --skip | --abort</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
Restore the original branch and abort the rebase operation.\r
</p>\r
</dd>\r
+<dt>\r
+--skip\r
+</dt>\r
+<dd>\r
+<p>\r
+ Restart the rebasing process by skipping the current patch.\r
+ This does not work with the --merge option.\r
+</p>\r
+</dd>\r
+<dt>\r
+--merge\r
+</dt>\r
+<dd>\r
+<p>\r
+ Use merging strategies to rebase. When the recursive (default) merge\r
+ strategy is used, this allows rebase to be aware of renames on the\r
+ upstream side.\r
+</p>\r
+</dd>\r
+<dt>\r
+-s <strategy>, --strategy=<strategy>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Use the given merge strategy; can be supplied more than\r
+ once to specify them in the order they should be tried.\r
+ If there is no <tt>-s</tt> option, a built-in list of strategies\r
+ is used instead (<tt>git-merge-recursive</tt> when merging a single\r
+ head, <tt>git-merge-octopus</tt> otherwise). This implies --merge.\r
+</p>\r
+</dd>\r
+</dl>\r
+</div>\r
+<h2>MERGE STRATEGIES</h2>\r
+<div class="sectionbody">\r
+<dl>\r
+<dt>\r
+resolve\r
+</dt>\r
+<dd>\r
+<p>\r
+ This can only resolve two heads (i.e. the current branch\r
+ and another branch you pulled from) using 3-way merge\r
+ algorithm. It tries to carefully detect criss-cross\r
+ merge ambiguities and is considered generally safe and\r
+ fast.\r
+</p>\r
+</dd>\r
+<dt>\r
+recursive\r
+</dt>\r
+<dd>\r
+<p>\r
+ This can only resolve two heads using 3-way merge\r
+ algorithm. When there are more than one common\r
+ ancestors that can be used for 3-way merge, it creates a\r
+ merged tree of the common ancestors and uses that as\r
+ the reference tree for the 3-way merge. This has been\r
+ reported to result in fewer merge conflicts without\r
+ causing mis-merges by tests done on actual merge commits\r
+ taken from Linux 2.6 kernel development history.\r
+ Additionally this can detect and handle merges involving\r
+ renames. This is the default merge strategy when\r
+ pulling or merging one branch.\r
+</p>\r
+</dd>\r
+<dt>\r
+octopus\r
+</dt>\r
+<dd>\r
+<p>\r
+ This resolves more than two-head case, but refuses to do\r
+ complex merge that needs manual resolution. It is\r
+ primarily meant to be used for bundling topic branch\r
+ heads together. This is the default merge strategy when\r
+ pulling or merging more than one branches.\r
+</p>\r
+</dd>\r
+<dt>\r
+ours\r
+</dt>\r
+<dd>\r
+<p>\r
+ This resolves any number of heads, but the result of the\r
+ merge is always the current branch head. It is meant to\r
+ be used to supersede old development history of side\r
+ branches.\r
+</p>\r
+</dd>\r
</dl>\r
</div>\r
<h2>NOTES</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 17-May-2006 10:34:04 UTC\r
+Last updated 22-Jun-2006 19:49:25 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-rebase' [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [--merge] [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
--abort::
Restore the original branch and abort the rebase operation.
+--skip::
+ Restart the rebasing process by skipping the current patch.
+ This does not work with the --merge option.
+
+--merge::
+ Use merging strategies to rebase. When the recursive (default) merge
+ strategy is used, this allows rebase to be aware of renames on the
+ upstream side.
+
+-s <strategy>, \--strategy=<strategy>::
+ Use the given merge strategy; can be supplied more than
+ once to specify them in the order they should be tried.
+ If there is no `-s` option, a built-in list of strategies
+ is used instead (`git-merge-recursive` when merging a single
+ head, `git-merge-octopus` otherwise). This implies --merge.
+
+include::merge-strategies.txt[]
+
NOTES
-----
When you rebase a branch, you are changing its history in a way that
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
<head>\r
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 7.0.1" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
<style type="text/css">\r
/* Debug borders */\r
p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
<p>This command is usually not invoked directly by the end user.\r
The UI for the protocol is on the <em>git-send-pack</em> side, and the\r
program pair is meant to be used to push updates to remote\r
-repository. For pull operations, see <em>git-fetch-pack</em> and\r
-<em>git-clone-pack</em>.</p>\r
+repository. For pull operations, see <em>git-fetch-pack</em>.</p>\r
<p>The command allows for creation and fast forwarding of sha1 refs\r
(heads/tags) on the remote end (strictly speaking, it is the\r
local end receive-pack runs, but to the user who is sitting at\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 27-Dec-2005 00:16:33 PDT\r
+Last updated 22-Jun-2006 19:49:25 UTC\r
</div>\r
</div>\r
</body>\r
This command is usually not invoked directly by the end user.
The UI for the protocol is on the 'git-send-pack' side, and the
program pair is meant to be used to push updates to remote
-repository. For pull operations, see 'git-fetch-pack' and
-'git-clone-pack'.
+repository. For pull operations, see 'git-fetch-pack'.
The command allows for creation and fast forwarding of sha1 refs
(heads/tags) on the remote end (strictly speaking, it is the
</dd>\r
</dl>\r
</div>\r
+<h2>ENVIRONMENT</h2>\r
+<div class="sectionbody">\r
+<dl>\r
+<dt>\r
+GIT_CONFIG\r
+</dt>\r
+<dd>\r
+<p>\r
+ Take the configuration from the given file instead of .git/config.\r
+</p>\r
+</dd>\r
+<dt>\r
+GIT_CONFIG_LOCAL\r
+</dt>\r
+<dd>\r
+<p>\r
+ Currently the same as $GIT_CONFIG; when Git will support global\r
+ configuration files, this will cause it to take the configuration\r
+ from the global configuration file in addition to the given file.\r
+</p>\r
+</dd>\r
+</dl>\r
+</div>\r
<h2>EXAMPLE</h2>\r
<div class="sectionbody">\r
<p>Given a .git/config like this:</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 08-Jun-2006 00:48:14 UTC\r
+Last updated 22-Jun-2006 19:49:26 UTC\r
</div>\r
</div>\r
</body>\r
List all variables set in .git/config.
+ENVIRONMENT
+-----------
+
+GIT_CONFIG::
+ Take the configuration from the given file instead of .git/config.
+
+GIT_CONFIG_LOCAL::
+ Currently the same as $GIT_CONFIG; when Git will support global
+ configuration files, this will cause it to take the configuration
+ from the global configuration file in addition to the given file.
+
+
EXAMPLE
-------
<p>The options available are:</p>\r
<dl>\r
<dt>\r
+--bcc\r
+</dt>\r
+<dd>\r
+<p>\r
+ Specify a "Bcc:" value for each email.\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>The --bcc option must be repeated for each user you want on the bcc list.</tt></pre>\r
+</div></div>\r
+</dd>\r
+<dt>\r
--cc\r
</dt>\r
<dd>\r
<p>\r
Specify a starting "Cc:" value for each email.\r
</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>The --cc option must be repeated for each user you want on the cc list.</tt></pre>\r
+</div></div>\r
</dd>\r
<dt>\r
--chain-reply-to, --no-chain-reply-to\r
Generally, this will be the upstream maintainer of the\r
project involved.\r
</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>The --to option must be repeated for each user you want on the to list.</tt></pre>\r
+</div></div>\r
</dd>\r
</dl>\r
</div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 04-Jun-2006 07:24:32 UTC\r
+Last updated 22-Jun-2006 19:49:26 UTC\r
</div>\r
</div>\r
</body>\r
-------
The options available are:
+--bcc::
+ Specify a "Bcc:" value for each email.
+
+ The --bcc option must be repeated for each user you want on the bcc list.
+
--cc::
Specify a starting "Cc:" value for each email.
+ The --cc option must be repeated for each user you want on the cc list.
+
--chain-reply-to, --no-chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
Generally, this will be the upstream maintainer of the
project involved.
+ The --to option must be repeated for each user you want on the to list.
+
Author
------
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
-<p>Invoked by <em>git-clone-pack</em> and/or <em>git-fetch-pack</em>, learns what\r
+<p>Invoked by <em>git-fetch-pack</em>, learns what\r
objects the other side is missing, and sends them after packing.</p>\r
<p>This command is usually not invoked directly by the end user.\r
The UI for the protocol is on the <em>git-fetch-pack</em> side, and the\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-Mar-2006 00:31:38 UTC\r
+Last updated 22-Jun-2006 19:49:27 UTC\r
</div>\r
</div>\r
</body>\r
DESCRIPTION
-----------
-Invoked by 'git-clone-pack' and/or 'git-fetch-pack', learns what
+Invoked by 'git-fetch-pack', learns what
objects the other side is missing, and sends them after packing.
This command is usually not invoked directly by the end user.
<h3>Synching repositories</h3>\r
<dl>\r
<dt>\r
-<a href="git-clone-pack.html">git-clone-pack(1)</a>\r
-</dt>\r
-<dd>\r
-<p>\r
- Clones a repository into the current repository (engine\r
- for ssh and local transport).\r
-</p>\r
-</dd>\r
-<dt>\r
<a href="git-fetch-pack.html">git-fetch-pack(1)</a>\r
</dt>\r
<dd>\r
</dt>\r
<dd>\r
<p>\r
- Invoked by <em>git-clone-pack</em> and <em>git-fetch-pack</em> to push\r
+ Invoked by <em>git-fetch-pack</em> to push\r
what are asked for.\r
</p>\r
</dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 07-Jun-2006 19:51:33 UTC\r
+Last updated 22-Jun-2006 19:49:27 UTC\r
</div>\r
</div>\r
</body>\r
Synching repositories
~~~~~~~~~~~~~~~~~~~~~
-gitlink:git-clone-pack[1]::
- Clones a repository into the current repository (engine
- for ssh and local transport).
-
gitlink:git-fetch-pack[1]::
Updates from a remote repository (engine for ssh and
local transport).
clients discover references and packs on it.
gitlink:git-upload-pack[1]::
- Invoked by 'git-clone-pack' and 'git-fetch-pack' to push
+ Invoked by 'git-fetch-pack' to push
what are asked for.
gitlink:git-upload-tar[1]::
projects / git.git / commitdiff