<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
<h2>NAME</h2>\r
<div class="sectionbody">\r
<p>git-pull -\r
- Pull and merge from another repository.\r
+ Pull and merge from another repository\r
</p>\r
</div>\r
</div>\r
</p>\r
</dd>\r
<dt>\r
+--upload-pack <upload-pack>\r
+</dt>\r
+<dd>\r
+<p>\r
+ When given, and the repository to fetch from is handled\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
+</dd>\r
+<dt>\r
-f, --force\r
</dt>\r
<dd>\r
</p>\r
</dd>\r
<dt>\r
+--no-tags\r
+</dt>\r
+<dd>\r
+<p>\r
+ By default, <tt>git-fetch</tt> fetches tags that point at\r
+ objects that are downloaded from the remote repository\r
+ and stores them locally. This option disables this\r
+ automatic tag following.\r
+</p>\r
+</dd>\r
+<dt>\r
-t, --tags\r
</dt>\r
<dd>\r
<p>\r
- By default, the git core utilities will not fetch and store\r
- tags under the same name as the remote repository; ask it\r
- to do so using <tt>--tags</tt>. Using this option will bound the\r
- list of objects pulled to the remote tags. Commits in branches\r
- beyond the tags will be ignored.\r
+ Most of the tags are fetched automatically as branch\r
+ heads are downloaded, but tags that do not point at\r
+ objects reachable from the branch heads that are being\r
+ tracked will not be fetched by this mechanism. This\r
+ flag lets all tags and their associated objects be\r
+ downloaded.\r
+</p>\r
+</dd>\r
+<dt>\r
+-k, --keep\r
+</dt>\r
+<dd>\r
+<p>\r
+ Keep downloaded pack.\r
</p>\r
</dd>\r
<dt>\r
<dd>\r
<p>\r
The "remote" repository that is the source of a fetch\r
- or pull operation, or the destination of a push operation.\r
- One of the following notations can be used\r
- to name the remote repository:\r
+ or pull operation. See the section <a href="#URLS">GIT URLS</a> below.\r
+</p>\r
+</dd>\r
+<dt>\r
+<refspec>\r
+</dt>\r
+<dd>\r
+<p>\r
+ The canonical format of a <refspec> parameter is\r
+ <tt>+?<src>:<dst></tt>; that is, an optional plus <tt>+</tt>, followed\r
+ by the source ref, followed by a colon <tt>:</tt>, followed by\r
+ the destination ref.\r
+</p>\r
+<p>The remote ref that matches <src>\r
+is fetched, and if <dst> is not empty string, the local\r
+ref that matches it is fast forwarded using <src>.\r
+Again, if the optional plus <tt>+</tt> is used, the local ref\r
+is updated even if it does not result in a fast forward\r
+update.</p>\r
+<div class="admonitionblock">\r
+<table><tr>\r
+<td class="icon">\r
+<div class="title">Note</div>\r
+</td>\r
+<td class="content">If the remote branch from which you want to pull is\r
+modified in non-linear ways such as being rewound and\r
+rebased frequently, then a pull will attempt a merge with\r
+an older version of itself, likely conflict, and fail.\r
+It is under these conditions that you would want to use\r
+the <tt>+</tt> sign to indicate non-fast-forward updates will\r
+be needed. There is currently no easy way to determine\r
+or declare that a branch will be made available in a\r
+repository with this behavior; the pulling user simply\r
+must know this is the expected usage pattern for a branch.</td>\r
+</tr></table>\r
+</div>\r
+<div class="admonitionblock">\r
+<table><tr>\r
+<td class="icon">\r
+<div class="title">Note</div>\r
+</td>\r
+<td class="content">You never do your own development on branches that appear\r
+on the right hand side of a <refspec> colon on <tt>Pull:</tt> lines;\r
+they are to be updated by <tt>git-fetch</tt>. If you intend to do\r
+development derived from a remote branch <tt>B</tt>, have a <tt>Pull:</tt>\r
+line to track it (i.e. <tt>Pull: B:remote-B</tt>), and have a separate\r
+branch <tt>my-B</tt> to do your development on top of it. The latter\r
+is created by <tt>git branch my-B remote-B</tt> (or its equivalent <tt>git\r
+checkout -b my-B remote-B</tt>). Run <tt>git fetch</tt> to keep track of\r
+the progress of the remote side, and when you see something new\r
+on the remote branch, merge it into your development branch with\r
+<tt>git pull . remote-B</tt>, while you are on <tt>my-B</tt> branch.\r
+The common <tt>Pull: master:origin</tt> mapping of a remote <tt>master</tt>\r
+branch to a local <tt>origin</tt> branch, which is then merged to a\r
+local development branch, again typically named <tt>master</tt>, is made\r
+when you run <tt>git clone</tt> for you to follow this pattern.</td>\r
+</tr></table>\r
+</div>\r
+<div class="admonitionblock">\r
+<table><tr>\r
+<td class="icon">\r
+<div class="title">Note</div>\r
+</td>\r
+<td class="content">There is a difference between listing multiple <refspec>\r
+directly on <tt>git-pull</tt> command line and having multiple\r
+<tt>Pull:</tt> <refspec> lines for a <repository> and running\r
+<tt>git-pull</tt> command without any explicit <refspec> parameters.\r
+<refspec> listed explicitly on the command line are always\r
+merged into the current branch after fetching. In other words,\r
+if you list more than one remote refs, you would be making\r
+an Octopus. While <tt>git-pull</tt> run without any explicit <refspec>\r
+parameter takes default <refspec>s from <tt>Pull:</tt> lines, it\r
+merges only the first <refspec> found into the current branch,\r
+after fetching all the remote refs. This is because making an\r
+Octopus from remote refs is rarely done, while keeping track\r
+of multiple remote heads in one-go by fetching more than one\r
+is often useful.</td>\r
+</tr></table>\r
+</div>\r
+<p>Some short-cut notations are also supported.</p>\r
+<ul>\r
+<li>\r
+<p>\r
+<tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;\r
+ it requests fetching everything up to the given tag.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+A parameter <ref> without a colon is equivalent to\r
+ <ref>: when pulling/fetching, so it merges <ref> into the current\r
+ branch without storing the remote branch anywhere locally\r
</p>\r
+</li>\r
+</ul>\r
+</dd>\r
+</dl>\r
+</div>\r
+<h2>GIT URLS<a id="URLS"></a></h2>\r
+<div class="sectionbody">\r
+<p>One of the following notations can be used\r
+to name the remote repository:</p>\r
<div class="exampleblock">\r
<div class="exampleblock-content">\r
<ul>\r
</li>\r
</ul>\r
</div></div>\r
+</div>\r
+<h2>REMOTES</h2>\r
+<div class="sectionbody">\r
<p>In addition to the above, as a short-hand, the name of a\r
file in <tt>$GIT_DIR/remotes</tt> directory can be given; the\r
named file should be in the following format:</p>\r
Push: <refspec>\r
Pull: <refspec></tt></pre>\r
</div></div>\r
-<p>When such a short-hand is specified in place of\r
+<p>Then such a short-hand is specified in place of\r
<repository> without <refspec> parameters on the command\r
line, <refspec> specified on <tt>Push:</tt> lines or <tt>Pull:</tt>\r
lines are used for <tt>git-push</tt> and <tt>git-fetch</tt>/<tt>git-pull</tt>,\r
<pre><tt>URL: <url>\r
Pull: refs/heads/<head>:<remote></tt></pre>\r
</div></div>\r
-</dd>\r
-<dt>\r
-<refspec>\r
-</dt>\r
-<dd>\r
-<p>\r
- The canonical format of a <refspec> parameter is\r
- <tt>+?<src>:<dst></tt>; that is, an optional plus <tt>+</tt>, followed\r
- by the source ref, followed by a colon <tt>:</tt>, followed by\r
- the destination ref.\r
-</p>\r
-<p>When used in <tt>git-push</tt>, the <src> side can be an\r
-arbitrary "SHA1 expression" that can be used as an\r
-argument to <tt>git-cat-file -t</tt>. E.g. <tt>master~4</tt> (push\r
-four parents before the current master head).</p>\r
-<p>For <tt>git-push</tt>, the local ref that matches <src> is used\r
-to fast forward the remote ref that matches <dst>. If\r
-the optional plus <tt>+</tt> is used, the remote ref is updated\r
-even if it does not result in a fast forward update.</p>\r
-<p>For <tt>git-fetch</tt> and <tt>git-pull</tt>, the remote ref that matches <src>\r
-is fetched, and if <dst> is not empty string, the local\r
-ref that matches it is fast forwarded using <src>.\r
-Again, if the optional plus <tt>+</tt> is used, the local ref\r
-is updated even if it does not result in a fast forward\r
-update.</p>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">If the remote branch from which you want to pull is\r
-modified in non-linear ways such as being rewound and\r
-rebased frequently, then a pull will attempt a merge with\r
-an older version of itself, likely conflict, and fail.\r
-It is under these conditions that you would want to use\r
-the <tt>+</tt> sign to indicate non-fast-forward updates will\r
-be needed. There is currently no easy way to determine\r
-or declare that a branch will be made available in a\r
-repository with this behavior; the pulling user simply\r
-must know this is the expected usage pattern for a branch.</td>\r
-</tr></table>\r
-</div>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">You never do your own development on branches that appear\r
-on the right hand side of a <refspec> colon on <tt>Pull:</tt> lines;\r
-they are to be updated by <tt>git-fetch</tt>. If you intend to do\r
-development derived from a remote branch <tt>B</tt>, have a <tt>Pull:</tt>\r
-line to track it (i.e. <tt>Pull: B:remote-B</tt>), and have a separate\r
-branch <tt>my-B</tt> to do your development on top of it. The latter\r
-is created by <tt>git branch my-B remote-B</tt> (or its equivalent <tt>git\r
-checkout -b my-B remote-B</tt>). Run <tt>git fetch</tt> to keep track of\r
-the progress of the remote side, and when you see something new\r
-on the remote branch, merge it into your development branch with\r
-<tt>git pull . remote-B</tt>, while you are on <tt>my-B</tt> branch.\r
-The common <tt>Pull: master:origin</tt> mapping of a remote <tt>master</tt>\r
-branch to a local <tt>origin</tt> branch, which is then merged to a\r
-local development branch, again typically named <tt>master</tt>, is made\r
-when you run <tt>git clone</tt> for you to follow this pattern.</td>\r
-</tr></table>\r
-</div>\r
-<div class="admonitionblock">\r
-<table><tr>\r
-<td class="icon">\r
-<div class="title">Note</div>\r
-</td>\r
-<td class="content">There is a difference between listing multiple <refspec>\r
-directly on <tt>git-pull</tt> command line and having multiple\r
-<tt>Pull:</tt> <refspec> lines for a <repository> and running\r
-<tt>git-pull</tt> command without any explicit <refspec> parameters.\r
-<refspec> listed explicitly on the command line are always\r
-merged into the current branch after fetching. In other words,\r
-if you list more than one remote refs, you would be making\r
-an Octopus. While <tt>git-pull</tt> run without any explicit <refspec>\r
-parameter takes default <refspec>s from <tt>Pull:</tt> lines, it\r
-merges only the first <refspec> found into the current branch,\r
-after fetching all the remote refs. This is because making an\r
-Octopus from remote refs is rarely done, while keeping track\r
-of multiple remote heads in one-go by fetching more than one\r
-is often useful.</td>\r
-</tr></table>\r
-</div>\r
-<p>Some short-cut notations are also supported.</p>\r
-<ul>\r
-<li>\r
-<p>\r
-For backward compatibility, <tt>tag</tt> is almost ignored;\r
- it just makes the following parameter <tag> to mean a\r
- refspec <tt>refs/tags/<tag>:refs/tags/<tag></tt>.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-A parameter <ref> without a colon is equivalent to\r
- <ref>: when pulling/fetching, and <ref><tt>:</tt><ref> when\r
- pushing. That is, do not store it locally if\r
- fetching, and update the same name if pushing.\r
-</p>\r
-</li>\r
-</ul>\r
-</dd>\r
-</dl>\r
</div>\r
<h2>MERGE STRATEGIES</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 27-Dec-2005 00:16:29 PDT\r
+Last updated 10-Mar-2006 00:31:31 UTC\r
</div>\r
</div>\r
</body>\r