<div class="content">\r
<pre><tt>$ git checkout mybranch\r
$ echo "Work, work, work" >>hello\r
-$ git commit -m 'Some work.' hello</tt></pre>\r
+$ git commit -m 'Some work.' -i hello</tt></pre>\r
</div></div>\r
<p>Here, we just added another line to <tt>hello</tt>, and we used a shorthand for\r
doing both <tt>git-update-index hello</tt> and <tt>git commit</tt> by just giving the\r
<div class="content">\r
<pre><tt>$ echo "Play, play, play" >>hello\r
$ echo "Lots of fun" >>example\r
-$ git commit -m 'Some fun.' hello example</tt></pre>\r
+$ git commit -m 'Some fun.' -i hello example</tt></pre>\r
</div></div>\r
<p>since the master branch is obviously in a much better mood.</p>\r
<p>Now, you've got two branches, and you decide that you want to merge the\r
<p>and once you're happy with your manual merge, just do a</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git commit hello</tt></pre>\r
+<pre><tt>$ git commit -i hello</tt></pre>\r
</div></div>\r
<p>which will very loudly warn you that you're now committing a merge\r
(which is correct, so never mind), and you can write a small merge\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 07-Feb-2006 03:24:18 UTC\r
+Last updated 07-Feb-2006 08:04:34 UTC\r
</div>\r
</div>\r
</body>\r
------------------------------------------------
$ git checkout mybranch
$ echo "Work, work, work" >>hello
-$ git commit -m 'Some work.' hello
+$ git commit -m 'Some work.' -i hello
------------------------------------------------
Here, we just added another line to `hello`, and we used a shorthand for
------------
$ echo "Play, play, play" >>hello
$ echo "Lots of fun" >>example
-$ git commit -m 'Some fun.' hello example
+$ git commit -m 'Some fun.' -i hello example
------------
since the master branch is obviously in a much better mood.
and once you're happy with your manual merge, just do a
------------
-$ git commit hello
+$ git commit -i hello
------------
which will very loudly warn you that you're now committing a merge
<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>SYNOPSIS</h2>\r
<div class="sectionbody">\r
<div class="verseblock">\r
-<div class="content"><em>git-commit</em> [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]\r
- [-e] [--] <file>…</div></div>\r
+<div class="content"><em>git-commit</em> [-a] [-i] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]\r
+ [-e] [--author <author>] [--] <file>…</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
+--author <author>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Override the author name used in the commit. Use\r
+ <tt>A U Thor <author@example.com></tt> format.\r
+</p>\r
+</dd>\r
+<dt>\r
-m <msg>\r
</dt>\r
<dd>\r
</p>\r
</dd>\r
<dt>\r
+-i|--include\r
+</dt>\r
+<dd>\r
+<p>\r
+ Instead of committing only the files specified on the\r
+ command line, update them in the index file and then\r
+ commit the whole index. This is the traditional\r
+ behaviour.\r
+</p>\r
+</dd>\r
+<dt>\r
—\r
</dt>\r
<dd>\r
</dt>\r
<dd>\r
<p>\r
- Update specified paths in the index file before committing.\r
+ Commit only the files specified on the command line.\r
+ This format cannot be used during a merge, nor when the\r
+ index and the latest commit does not match on the\r
+ specified paths to avoid confusion.\r
</p>\r
</dd>\r
</dl>\r
<p>If you make a commit and then found a mistake immediately after\r
that, you can recover from it with <a href="git-reset.html">git-reset(1)</a>.</p>\r
</div>\r
+<h2>Discussion</h2>\r
+<div class="sectionbody">\r
+<p><tt>git commit</tt> without _any_ parameter commits the tree structure\r
+recorded by the current index file. This is a whole-tree commit\r
+even the command is invoked from a subdirectory.</p>\r
+<p><tt>git commit --include paths…</tt> is equivalent to</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>git update-index --remove paths...\r
+git commit</tt></pre>\r
+</div></div>\r
+<p>That is, update the specified paths to the index and then commit\r
+the whole tree.</p>\r
+<p><tt>git commit paths…</tt> largely bypasses the index file and\r
+commits only the changes made to the specified paths. It has\r
+however several safety valves to prevent confusion.</p>\r
+<ol>\r
+<li>\r
+<p>\r
+It refuses to run during a merge (i.e. when\r
+ <tt>$GIT_DIR/MERGE_HEAD</tt> exists), and reminds trained git users\r
+ that the traditional semantics now needs -i flag.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+It refuses to run if named <tt>paths…</tt> are different in HEAD\r
+ and the index (ditto about reminding). Added paths are OK.\r
+ This is because an earlier <tt>git diff</tt> (not <tt>git diff HEAD</tt>)\r
+ would have shown the differences since the last <tt>git\r
+ update-index paths…</tt> to the user, and an inexperienced user\r
+ may mistakenly think that the changes between the index and\r
+ the HEAD (i.e. earlier changes made before the last <tt>git\r
+ update-index paths…</tt> was done) are not being committed.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+It reads HEAD commit into a temporary index file, updates the\r
+ specified <tt>paths…</tt> and makes a commit. At the same time,\r
+ the real index file is also updated with the same <tt>paths…</tt>.\r
+</p>\r
+</li>\r
+</ol>\r
+<p><tt>git commit --all</tt> updates the index file with _all_ changes to\r
+the working tree, and makes a whole-tree commit, regardless of\r
+which subdirectory the command is invoked in.</p>\r
+</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
<p>Written by Linus Torvalds <torvalds@osdl.org> and\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 21-Jan-2006 23:50:16 PDT\r
+Last updated 07-Feb-2006 08:04:29 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
[verse]
-'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
- [-e] [--] <file>...
+'git-commit' [-a] [-i] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
+ [-e] [--author <author>] [--] <file>...
DESCRIPTION
-----------
Take the commit message from the given file. Use '-' to
read the message from the standard input.
+--author <author>::
+ Override the author name used in the commit. Use
+ `A U Thor <author@example.com>` format.
+
-m <msg>::
Use the given <msg> as the commit message.
commit log message unmodified. This option lets you
further edit the message taken from these sources.
+-i|--include::
+ Instead of committing only the files specified on the
+ command line, update them in the index file and then
+ commit the whole index. This is the traditional
+ behaviour.
+
--::
Do not interpret any more arguments as options.
<file>...::
- Update specified paths in the index file before committing.
-
+ Commit only the files specified on the command line.
+ This format cannot be used during a merge, nor when the
+ index and the latest commit does not match on the
+ specified paths to avoid confusion.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
+Discussion
+----------
+
+`git commit` without _any_ parameter commits the tree structure
+recorded by the current index file. This is a whole-tree commit
+even the command is invoked from a subdirectory.
+
+`git commit --include paths...` is equivalent to
+
+ git update-index --remove paths...
+ git commit
+
+That is, update the specified paths to the index and then commit
+the whole tree.
+
+`git commit paths...` largely bypasses the index file and
+commits only the changes made to the specified paths. It has
+however several safety valves to prevent confusion.
+
+. It refuses to run during a merge (i.e. when
+ `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
+ that the traditional semantics now needs -i flag.
+
+. It refuses to run if named `paths...` are different in HEAD
+ and the index (ditto about reminding). Added paths are OK.
+ This is because an earlier `git diff` (not `git diff HEAD`)
+ would have shown the differences since the last `git
+ update-index paths...` to the user, and an inexperienced user
+ may mistakenly think that the changes between the index and
+ the HEAD (i.e. earlier changes made before the last `git
+ update-index paths...` was done) are not being committed.
+
+. It reads HEAD commit into a temporary index file, updates the
+ specified `paths...` and makes a commit. At the same time,
+ the real index file is also updated with the same `paths...`.
+
+`git commit --all` updates the index file with _all_ changes to
+the working tree, and makes a whole-tree commit, regardless of
+which subdirectory the command is invoked in.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
<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
<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
-<tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;\r
- used with pull or fetch, it requests fetching everything up to\r
- 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, 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>SEE ALSO</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 26-Jan-2006 19:38:18 PDT\r
+Last updated 07-Feb-2006 08:04:30 UTC\r
</div>\r
</div>\r
</body>\r
include::pull-fetch-param.txt[]
-
+include::urls.txt[]
SEE ALSO
--------
<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
<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
-<tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;\r
- used with pull or fetch, it requests fetching everything up to\r
- 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, 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 26-Jan-2006 19:38:19 PDT\r
+Last updated 07-Feb-2006 08:04:30 UTC\r
</div>\r
</div>\r
</body>\r
include::pull-fetch-param.txt[]
-include::merge-strategies.txt[]
+include::urls.txt[]
+include::merge-strategies.txt[]
EXAMPLES
--------
<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
<div class="sectionbody">\r
<p>Updates remote refs using local refs, while sending objects\r
necessary to complete the given refs.</p>\r
-<p>You can make "interesting" things to happen on the repository\r
+<p>You can make interesting things happen to a repository\r
every time you push into it, by setting up <em>hooks</em> there. See\r
documentation for <a href="git-receive-pack.html">git-receive-pack(1)</a>.</p>\r
</div>\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
+ The "remote" repository that is destination of a push\r
+ 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 <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>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>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
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+A parameter <ref> without a colon is equivalent to\r
+ <ref><tt>:</tt><ref>, hence updates <ref> in the destination from <ref>\r
+ in the source.\r
+</p>\r
+</li>\r
+</ul>\r
+</dd>\r
+<dt>\r
+--all\r
+</dt>\r
+<dd>\r
+<p>\r
+ Instead of naming each ref to push, specifies that all\r
+ refs be pushed.\r
+</p>\r
+</dd>\r
+<dt>\r
+--tags\r
+</dt>\r
+<dd>\r
+<p>\r
+ All refs under <tt>$GIT_DIR/refs/tags</tt> are pushed, in\r
+ addition to refspecs explicitly listed on the command\r
+ line.\r
+</p>\r
+</dd>\r
+<dt>\r
+-f, --force\r
+</dt>\r
+<dd>\r
+<p>\r
+ Usually, the command refuses to update a remote ref that is\r
+ not a descendent of the local ref used to overwrite it.\r
+ This flag disables the check. This can cause the\r
+ remote repository to lose commits; use it with care.\r
+</p>\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
-<tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;\r
- used with pull or fetch, it requests fetching everything up to\r
- 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, 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
-<dt>\r
---all\r
-</dt>\r
-<dd>\r
-<p>\r
- Instead of naming each ref to push, specifies all refs\r
- to be pushed.\r
-</p>\r
-</dd>\r
-<dt>\r
---tags\r
-</dt>\r
-<dd>\r
-<p>\r
- All refs under <tt>$GIT_DIR/refs/tags</tt> are pushed, in\r
- addition to refspecs explicitly listed on the command\r
- line.\r
-</p>\r
-</dd>\r
-<dt>\r
--f, --force\r
-</dt>\r
-<dd>\r
-<p>\r
- Usually, the command refuses to update a remote ref that is\r
- not a descendent of the local ref used to overwrite it.\r
- This flag disables the check. This can cause the\r
- remote repository to lose commits; use it with care.\r
-</p>\r
-</dd>\r
-</dl>\r
</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 29-Jan-2006 20:18:18 PDT\r
+Last updated 07-Feb-2006 08:04:31 UTC\r
</div>\r
</div>\r
</body>\r
Updates remote refs using local refs, while sending objects
necessary to complete the given refs.
-You can make "interesting" things to happen on the repository
+You can make interesting things happen to a repository
every time you push into it, by setting up 'hooks' there. See
documentation for gitlink:git-receive-pack[1].
OPTIONS
-------
-include::pull-fetch-param.txt[]
+<repository>::
+ The "remote" repository that is destination of a push
+ operation. See the section <<URLS,GIT URLS>> below.
+
+<refspec>::
+ The canonical format of a <refspec> parameter is
+ `+?<src>:<dst>`; that is, an optional plus `+`, followed
+ by the source ref, followed by a colon `:`, followed by
+ the destination ref.
++
+The <src> side can be an
+arbitrary "SHA1 expression" that can be used as an
+argument to `git-cat-file -t`. E.g. `master~4` (push
+four parents before the current master head).
++
+The local ref that matches <src> is used
+to fast forward the remote ref that matches <dst>. If
+the optional plus `+` is used, the remote ref is updated
+even if it does not result in a fast forward update.
++
+Some short-cut notations are also supported.
++
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+* A parameter <ref> without a colon is equivalent to
+ <ref>`:`<ref>, hence updates <ref> in the destination from <ref>
+ in the source.
\--all::
- Instead of naming each ref to push, specifies all refs
- to be pushed.
+ Instead of naming each ref to push, specifies that all
+ refs be pushed.
\--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
+include::urls.txt[]
Author
------
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"\r
+ "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\r
+<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.2" />\r
+<style type="text/css">\r
+/* Debug borders */\r
+p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
+/*\r
+ border: 1px solid red;\r
+*/\r
+}\r
+\r
+body {\r
+ margin: 1em 5% 1em 5%;\r
+}\r
+\r
+a { color: blue; }\r
+a:visited { color: fuchsia; }\r
+\r
+em {\r
+ font-style: italic;\r
+}\r
+\r
+strong {\r
+ font-weight: bold;\r
+}\r
+\r
+tt {\r
+ color: navy;\r
+}\r
+\r
+h1, h2, h3, h4, h5, h6 {\r
+ color: #527bbd;\r
+ font-family: sans-serif;\r
+ margin-top: 1.2em;\r
+ margin-bottom: 0.5em;\r
+ line-height: 1.3;\r
+}\r
+\r
+h1 {\r
+ border-bottom: 2px solid silver;\r
+}\r
+h2 {\r
+ border-bottom: 2px solid silver;\r
+ padding-top: 0.5em;\r
+}\r
+\r
+div.sectionbody {\r
+ font-family: serif;\r
+ margin-left: 0;\r
+}\r
+\r
+hr {\r
+ border: 1px solid silver;\r
+}\r
+\r
+p {\r
+ margin-top: 0.5em;\r
+ margin-bottom: 0.5em;\r
+}\r
+\r
+pre {\r
+ padding: 0;\r
+ margin: 0;\r
+}\r
+\r
+span#author {\r
+ color: #527bbd;\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ font-size: 1.2em;\r
+}\r
+span#email {\r
+}\r
+span#revision {\r
+ font-family: sans-serif;\r
+}\r
+\r
+div#footer {\r
+ font-family: sans-serif;\r
+ font-size: small;\r
+ border-top: 2px solid silver;\r
+ padding-top: 0.5em;\r
+ margin-top: 4.0em;\r
+}\r
+div#footer-text {\r
+ float: left;\r
+ padding-bottom: 0.5em;\r
+}\r
+div#footer-badges {\r
+ float: right;\r
+ padding-bottom: 0.5em;\r
+}\r
+\r
+div#preamble,\r
+div.tableblock, div.imageblock, div.exampleblock, div.verseblock,\r
+div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,\r
+div.admonitionblock {\r
+ margin-right: 10%;\r
+ margin-top: 1.5em;\r
+ margin-bottom: 1.5em;\r
+}\r
+div.admonitionblock {\r
+ margin-top: 2.5em;\r
+ margin-bottom: 2.5em;\r
+}\r
+\r
+div.content { /* Block element content. */\r
+ padding: 0;\r
+}\r
+\r
+/* Block element titles. */\r
+div.title, caption.title {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ text-align: left;\r
+ margin-top: 1.0em;\r
+ margin-bottom: 0.5em;\r
+}\r
+div.title + * {\r
+ margin-top: 0;\r
+}\r
+\r
+td div.title:first-child {\r
+ margin-top: 0.0em;\r
+}\r
+div.content div.title:first-child {\r
+ margin-top: 0.0em;\r
+}\r
+div.content + div.title {\r
+ margin-top: 0.0em;\r
+}\r
+\r
+div.sidebarblock > div.content {\r
+ background: #ffffee;\r
+ border: 1px solid silver;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.listingblock > div.content {\r
+ border: 1px solid silver;\r
+ background: #f4f4f4;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.quoteblock > div.content {\r
+ padding-left: 2.0em;\r
+}\r
+div.quoteblock .attribution {\r
+ text-align: right;\r
+}\r
+\r
+div.admonitionblock .icon {\r
+ vertical-align: top;\r
+ font-size: 1.1em;\r
+ font-weight: bold;\r
+ text-decoration: underline;\r
+ color: #527bbd;\r
+ padding-right: 0.5em;\r
+}\r
+div.admonitionblock td.content {\r
+ padding-left: 0.5em;\r
+ border-left: 2px solid silver;\r
+}\r
+\r
+div.exampleblock > div.content {\r
+ border-left: 2px solid silver;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.verseblock div.content {\r
+ white-space: pre;\r
+}\r
+\r
+div.imageblock div.content { padding-left: 0; }\r
+div.imageblock img { border: 1px solid silver; }\r
+span.image img { border-style: none; }\r
+\r
+dl {\r
+ margin-top: 0.8em;\r
+ margin-bottom: 0.8em;\r
+}\r
+dt {\r
+ margin-top: 0.5em;\r
+ margin-bottom: 0;\r
+ font-style: italic;\r
+}\r
+dd > *:first-child {\r
+ margin-top: 0;\r
+}\r
+\r
+ul, ol {\r
+ list-style-position: outside;\r
+}\r
+ol.olist2 {\r
+ list-style-type: lower-alpha;\r
+}\r
+\r
+div.tableblock > table {\r
+ border-color: #527bbd;\r
+ border-width: 3px;\r
+}\r
+thead {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+}\r
+tfoot {\r
+ font-weight: bold;\r
+}\r
+\r
+div.hlist {\r
+ margin-top: 0.8em;\r
+ margin-bottom: 0.8em;\r
+}\r
+td.hlist1 {\r
+ vertical-align: top;\r
+ font-style: italic;\r
+ padding-right: 0.8em;\r
+}\r
+td.hlist2 {\r
+ vertical-align: top;\r
+}\r
+\r
+@media print {\r
+ div#footer-badges { display: none; }\r
+}\r
+include::./stylesheets/xhtml11-manpage.css[]\r
+/* Workarounds for IE6's broken and incomplete CSS2. */\r
+\r
+div.sidebar-content {\r
+ background: #ffffee;\r
+ border: 1px solid silver;\r
+ padding: 0.5em;\r
+}\r
+div.sidebar-title, div.image-title {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ margin-top: 0.0em;\r
+ margin-bottom: 0.5em;\r
+}\r
+\r
+div.listingblock div.content {\r
+ border: 1px solid silver;\r
+ background: #f4f4f4;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.quoteblock-content {\r
+ padding-left: 2.0em;\r
+}\r
+\r
+div.exampleblock-content {\r
+ border-left: 2px solid silver;\r
+ padding-left: 0.5em;\r
+}\r
+</style>\r
+<title>git-rerere(1)</title>\r
+</head>\r
+<body>\r
+<div id="header">\r
+<h1>\r
+git-rerere(1) Manual Page\r
+</h1>\r
+<h2>NAME</h2>\r
+<div class="sectionbody">\r
+<p>git-rerere -\r
+ Reuse recorded resolve\r
+</p>\r
+</div>\r
+</div>\r
+<h2>SYNOPSIS</h2>\r
+<div class="sectionbody">\r
+<p><em>git-rerere</em></p>\r
+</div>\r
+<h2>DESCRIPTION</h2>\r
+<div class="sectionbody">\r
+<p>In a workflow that employs relatively long lived topic branches,\r
+the developer sometimes needs to resolve the same conflict over\r
+and over again until the topic branches are done (either merged\r
+to the "release" branch, or sent out and accepted upstream).</p>\r
+<p>This command helps this process by recording conflicted\r
+automerge results and corresponding hand-resolve results on the\r
+initial manual merge, and later by noticing the same automerge\r
+results and applying the previously recorded hand resolution.</p>\r
+<div class="admonitionblock">\r
+<table><tr>\r
+<td class="icon">\r
+<div class="title">Note</div>\r
+</td>\r
+<td class="content">You need to create <tt>$GIT_DIR/rr-cache</tt> directory to enable this\r
+command.</td>\r
+</tr></table>\r
+</div>\r
+</div>\r
+<h2>DISCUSSION</h2>\r
+<div class="sectionbody">\r
+<p>When your topic branch modifies overlapping area that your\r
+master branch (or upstream) touched since your topic branch\r
+forked from it, you may want to test it with the latest master,\r
+even before your topic branch is ready to be pushed upstream:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> o---*---o topic\r
+ /\r
+ o---o---o---*---o---o master</tt></pre>\r
+</div></div>\r
+<p>For such a test, you need to merge master and topic somehow.\r
+One way to do it is to pull master into the topic branch:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> $ git checkout topic\r
+ $ git pull . master\r
+\r
+ o---*---o---+ topic\r
+ / /\r
+ o---o---o---*---o---o master</tt></pre>\r
+</div></div>\r
+<p>The commits marked with <tt>*</tt> touch the same area in the same\r
+file; you need to resolve the conflicts when creating the commit\r
+marked with <tt>+</tt>. Then you can test the result to make sure your\r
+work-in-progress still works with what is in the latest master.</p>\r
+<p>After this test merge, there are two ways to continue your work\r
+on the topic. The easiest is to build on top of the test merge\r
+commit <tt>+</tt>, and when your work in the topic branch is finally\r
+ready, pull the topic branch into master, and/or ask the\r
+upstream to pull from you. By that time, however, the master or\r
+the upstream might have been advanced since the test merge <tt>+</tt>,\r
+in which case the final commit graph would look like this:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> $ git checkout topic\r
+ $ git pull . master\r
+ $ ... work on both topic and master branches\r
+ $ git checkout master\r
+ $ git pull . topic\r
+\r
+ o---*---o---+---o---o topic\r
+ / / \\r
+ o---o---o---*---o---o---o---o---+ master</tt></pre>\r
+</div></div>\r
+<p>When your topic branch is long-lived, however, your topic branch\r
+would end up having many such "Merge from master" commits on it,\r
+which would unnecessarily clutter the development history.\r
+Readers of the Linux kernel mailing list may remember that Linus\r
+complained about such too frequent test merges when a subsystem\r
+maintainer asked to pull from a branch full of "useless merges".</p>\r
+<p>As an alternative, to keep the topic branch clean of test\r
+merges, you could blow away the test merge, and keep building on\r
+top of the tip before the test merge:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> $ git checkout topic\r
+ $ git pull . master\r
+ $ git reset --hard HEAD^ ;# rewind the test merge\r
+ $ ... work on both topic and master branches\r
+ $ git checkout master\r
+ $ git pull . topic\r
+\r
+ o---*---o-------o---o topic\r
+ / \\r
+ o---o---o---*---o---o---o---o---+ master</tt></pre>\r
+</div></div>\r
+<p>This would leave only one merge commit when your topic branch is\r
+finally ready and merged into the master branch. This merge\r
+would require you to resolve the conflict, introduced by the\r
+commits marked with <tt>*</tt>. However, often this conflict is the\r
+same conflict you resolved when you created the test merge you\r
+blew away. <tt>git-rerere</tt> command helps you to resolve this final\r
+conflicted merge using the information from your earlier hand\r
+resolve.</p>\r
+<p>Running <tt>git-rerere</tt> command immediately after a conflicted\r
+automerge records the conflicted working tree files, with the\r
+usual conflict markers <tt><<<<<<<</tt>, <tt>=======</tt>, and <tt>>>>>>>></tt> in\r
+them. Later, after you are done resolving the conflicts,\r
+running <tt>git-rerere</tt> again records the resolved state of these\r
+files. Suppose you did this when you created the test merge of\r
+master into the topic branch.</p>\r
+<p>Next time, running <tt>git-rerere</tt> after seeing a conflicted\r
+automerge, if the conflict is the same as the earlier one\r
+recorded, it is noticed and a three-way merge between the\r
+earlier conflicted automerge, the earlier manual resolution, and\r
+the current conflicted automerge is performed by the command.\r
+If this three-way merge resolves cleanly, the result is written\r
+out to your working tree file, so you would not have to manually\r
+resolve it. Note that <tt>git-rerere</tt> leaves the index file alone,\r
+so you still need to do the final sanity checks with <tt>git diff</tt>\r
+(or <tt>git diff -c</tt>) and <tt>git update-index</tt> when you are\r
+satisfied.</p>\r
+<p>As a convenience measure, <tt>git-merge</tt> automatically invokes\r
+<tt>git-rerere</tt> when it exits with a failed automerge, which\r
+records it if it is a new conflict, or reuses the earlier hand\r
+resolve when it is not. <tt>git-commit</tt> also invokes <tt>git-rerere</tt>\r
+when recording a merge result. What this means is that you do\r
+not have to do anything special yourself (Note: you still have\r
+to create <tt>$GIT_DIR/rr-cache</tt> directory to enable this command).</p>\r
+<p>In our example, when you did the test merge, the manual\r
+resolution is recorded, and it will be reused when you do the\r
+actual merge later with updated master and topic branch, as long\r
+as the earlier resolution is still applicable.</p>\r
+<p>The information <tt>git-rerere</tt> records is also used when running\r
+<tt>git-rebase</tt>. After blowing away the test merge and continuing\r
+development on the topic branch:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> o---*---o-------o---o topic\r
+ /\r
+ o---o---o---*---o---o---o---o master\r
+\r
+ $ git rebase master topic\r
+\r
+ o---*---o-------o---o topic\r
+ /\r
+ o---o---o---*---o---o---o---o master</tt></pre>\r
+</div></div>\r
+<p>you could run <tt>git rebase master topic</tt>, to keep yourself\r
+up-to-date even before your topic is ready to be sent upstream.\r
+This would result in falling back to three-way merge, and it\r
+would conflict the same way the test merge you resolved earlier.\r
+<tt>git-rerere</tt> is run by <tt>git rebase</tt> to help you resolve this\r
+conflict.</p>\r
+</div>\r
+<h2>Author</h2>\r
+<div class="sectionbody">\r
+<p>Written by Junio C Hamano <junkio@cox.net></p>\r
+</div>\r
+<h2>GIT</h2>\r
+<div class="sectionbody">\r
+<p>Part of the <a href="git.html">git(7)</a> suite</p>\r
+</div>\r
+<div id="footer">\r
+<div id="footer-text">\r
+Last updated 07-Feb-2006 08:04:31 UTC\r
+</div>\r
+</div>\r
+</body>\r
+</html>\r
--- /dev/null
+git-rerere(1)
+=============
+
+NAME
+----
+git-rerere - Reuse recorded resolve
+
+SYNOPSIS
+--------
+'git-rerere'
+
+
+DESCRIPTION
+-----------
+
+In a workflow that employs relatively long lived topic branches,
+the developer sometimes needs to resolve the same conflict over
+and over again until the topic branches are done (either merged
+to the "release" branch, or sent out and accepted upstream).
+
+This command helps this process by recording conflicted
+automerge results and corresponding hand-resolve results on the
+initial manual merge, and later by noticing the same automerge
+results and applying the previously recorded hand resolution.
+
+[NOTE]
+You need to create `$GIT_DIR/rr-cache` directory to enable this
+command.
+
+DISCUSSION
+----------
+
+When your topic branch modifies overlapping area that your
+master branch (or upstream) touched since your topic branch
+forked from it, you may want to test it with the latest master,
+even before your topic branch is ready to be pushed upstream:
+
+------------
+ o---*---o topic
+ /
+ o---o---o---*---o---o master
+------------
+
+For such a test, you need to merge master and topic somehow.
+One way to do it is to pull master into the topic branch:
+
+------------
+ $ git checkout topic
+ $ git pull . master
+
+ o---*---o---+ topic
+ / /
+ o---o---o---*---o---o master
+------------
+
+The commits marked with `*` touch the same area in the same
+file; you need to resolve the conflicts when creating the commit
+marked with `+`. Then you can test the result to make sure your
+work-in-progress still works with what is in the latest master.
+
+After this test merge, there are two ways to continue your work
+on the topic. The easiest is to build on top of the test merge
+commit `+`, and when your work in the topic branch is finally
+ready, pull the topic branch into master, and/or ask the
+upstream to pull from you. By that time, however, the master or
+the upstream might have been advanced since the test merge `+`,
+in which case the final commit graph would look like this:
+
+------------
+ $ git checkout topic
+ $ git pull . master
+ $ ... work on both topic and master branches
+ $ git checkout master
+ $ git pull . topic
+
+ o---*---o---+---o---o topic
+ / / \
+ o---o---o---*---o---o---o---o---+ master
+------------
+
+When your topic branch is long-lived, however, your topic branch
+would end up having many such "Merge from master" commits on it,
+which would unnecessarily clutter the development history.
+Readers of the Linux kernel mailing list may remember that Linus
+complained about such too frequent test merges when a subsystem
+maintainer asked to pull from a branch full of "useless merges".
+
+As an alternative, to keep the topic branch clean of test
+merges, you could blow away the test merge, and keep building on
+top of the tip before the test merge:
+
+------------
+ $ git checkout topic
+ $ git pull . master
+ $ git reset --hard HEAD^ ;# rewind the test merge
+ $ ... work on both topic and master branches
+ $ git checkout master
+ $ git pull . topic
+
+ o---*---o-------o---o topic
+ / \
+ o---o---o---*---o---o---o---o---+ master
+------------
+
+This would leave only one merge commit when your topic branch is
+finally ready and merged into the master branch. This merge
+would require you to resolve the conflict, introduced by the
+commits marked with `*`. However, often this conflict is the
+same conflict you resolved when you created the test merge you
+blew away. `git-rerere` command helps you to resolve this final
+conflicted merge using the information from your earlier hand
+resolve.
+
+Running `git-rerere` command immediately after a conflicted
+automerge records the conflicted working tree files, with the
+usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
+them. Later, after you are done resolving the conflicts,
+running `git-rerere` again records the resolved state of these
+files. Suppose you did this when you created the test merge of
+master into the topic branch.
+
+Next time, running `git-rerere` after seeing a conflicted
+automerge, if the conflict is the same as the earlier one
+recorded, it is noticed and a three-way merge between the
+earlier conflicted automerge, the earlier manual resolution, and
+the current conflicted automerge is performed by the command.
+If this three-way merge resolves cleanly, the result is written
+out to your working tree file, so you would not have to manually
+resolve it. Note that `git-rerere` leaves the index file alone,
+so you still need to do the final sanity checks with `git diff`
+(or `git diff -c`) and `git update-index` when you are
+satisfied.
+
+As a convenience measure, `git-merge` automatically invokes
+`git-rerere` when it exits with a failed automerge, which
+records it if it is a new conflict, or reuses the earlier hand
+resolve when it is not. `git-commit` also invokes `git-rerere`
+when recording a merge result. What this means is that you do
+not have to do anything special yourself (Note: you still have
+to create `$GIT_DIR/rr-cache` directory to enable this command).
+
+In our example, when you did the test merge, the manual
+resolution is recorded, and it will be reused when you do the
+actual merge later with updated master and topic branch, as long
+as the earlier resolution is still applicable.
+
+The information `git-rerere` records is also used when running
+`git-rebase`. After blowing away the test merge and continuing
+development on the topic branch:
+
+------------
+ o---*---o-------o---o topic
+ /
+ o---o---o---*---o---o---o---o master
+
+ $ git rebase master topic
+
+ o---*---o-------o---o topic
+ /
+ o---o---o---*---o---o---o---o master
+------------
+
+you could run `git rebase master topic`, to keep yourself
+up-to-date even before your topic is ready to be sent upstream.
+This would result in falling back to three-way merge, and it
+would conflict the same way the test merge you resolved earlier.
+`git-rerere` is run by `git rebase` to help you resolve this
+conflict.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite
<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>\r
</dd>\r
<dt>\r
+<a href="git-rerere.html">git-rerere(1)</a>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Reuse recorded resolution of conflicted merges.\r
+</p>\r
+</dd>\r
+<dt>\r
<a href="git-reset.html">git-reset(1)</a>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 25-Jan-2006 04:37:14 PDT\r
+Last updated 07-Feb-2006 08:04:32 UTC\r
</div>\r
</div>\r
</body>\r
gitlink:git-repack[1]::
Pack unpacked objects in a repository.
+gitlink:git-rerere[1]::
+ Reuse recorded resolution of conflicted merges.
+
gitlink:git-reset[1]::
Reset current HEAD to the specified state.
<repository>::
The "remote" repository that is the source of a fetch
- or pull operation, or the destination of a push operation.
- One of the following notations can be used
- to name the remote repository:
-+
-===============================================================
-- rsync://host.xz/path/to/repo.git/
-- http://host.xz/path/to/repo.git/
-- https://host.xz/path/to/repo.git/
-- git://host.xz/path/to/repo.git/
-- git://host.xz/~user/path/to/repo.git/
-- ssh://host.xz/path/to/repo.git/
-- ssh://host.xz/~user/path/to/repo.git/
-- ssh://host.xz/~/path/to/repo.git
-===============================================================
-+
-SSH Is the default transport protocol and also supports an
-scp-like syntax. Both syntaxes support username expansion,
-as does the native git protocol. The following three are
-identical to the last three above, respectively:
-+
-===============================================================
-- host.xz:/path/to/repo.git/
-- host.xz:~user/path/to/repo.git/
-- host.xz:path/to/repo.git
-===============================================================
-+
-To sync with a local directory, use:
-+
-===============================================================
-- /path/to/repo.git/
-===============================================================
-+
-In addition to the above, as a short-hand, the name of a
-file in `$GIT_DIR/remotes` directory can be given; the
-named file should be in the following format:
-+
- URL: one of the above URL format
- Push: <refspec>
- Pull: <refspec>
-+
-When such a short-hand is specified in place of
-<repository> without <refspec> parameters on the command
-line, <refspec> specified on `Push:` lines or `Pull:`
-lines are used for `git-push` and `git-fetch`/`git-pull`,
-respectively. Multiple `Push:` and and `Pull:` lines may
-be specified for additional branch mappings.
-+
-The name of a file in `$GIT_DIR/branches` directory can be
-specified as an older notation short-hand; the named
-file should contain a single line, a URL in one of the
-above formats, optionally followed by a hash `#` and the
-name of remote head (URL fragment notation).
-`$GIT_DIR/branches/<remote>` file that stores a <url>
-without the fragment is equivalent to have this in the
-corresponding file in the `$GIT_DIR/remotes/` directory.
-+
- URL: <url>
- Pull: refs/heads/master:<remote>
-+
-while having `<url>#<head>` is equivalent to
-+
- URL: <url>
- Pull: refs/heads/<head>:<remote>
+ or pull operation. See the section <<URLS,GIT URLS>> below.
<refspec>::
The canonical format of a <refspec> parameter is
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
-When used in `git-push`, the <src> side can be an
-arbitrary "SHA1 expression" that can be used as an
-argument to `git-cat-file -t`. E.g. `master~4` (push
-four parents before the current master head).
-+
-For `git-push`, the local ref that matches <src> is used
-to fast forward the remote ref that matches <dst>. If
-the optional plus `+` is used, the remote ref is updated
-even if it does not result in a fast forward update.
-+
-For `git-fetch` and `git-pull`, the remote ref that matches <src>
+The remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
ref that matches it is fast forwarded using <src>.
Again, if the optional plus `+` is used, the local ref
Some short-cut notations are also supported.
+
* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
- used with pull or fetch, it requests fetching everything up to
- the given tag.
+ it requests fetching everything up to the given tag.
* A parameter <ref> without a colon is equivalent to
- <ref>: when pulling/fetching, and <ref>`:`<ref> when
- pushing. That is, do not store it locally if
- fetching, and update the same name if pushing.
-
+ <ref>: when pulling/fetching, so it merges <ref> into the current
+ branch without storing the remote branch anywhere locally
--- /dev/null
+GIT URLS[[URLS]]
+----------------
+
+One of the following notations can be used
+to name the remote repository:
+
+===============================================================
+- rsync://host.xz/path/to/repo.git/
+- http://host.xz/path/to/repo.git/
+- https://host.xz/path/to/repo.git/
+- git://host.xz/path/to/repo.git/
+- git://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/path/to/repo.git/
+- ssh://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/~/path/to/repo.git
+===============================================================
+
+SSH Is the default transport protocol and also supports an
+scp-like syntax. Both syntaxes support username expansion,
+as does the native git protocol. The following three are
+identical to the last three above, respectively:
+
+===============================================================
+- host.xz:/path/to/repo.git/
+- host.xz:~user/path/to/repo.git/
+- host.xz:path/to/repo.git
+===============================================================
+
+To sync with a local directory, use:
+
+===============================================================
+- /path/to/repo.git/
+===============================================================
+
+REMOTES
+-------
+
+In addition to the above, as a short-hand, the name of a
+file in `$GIT_DIR/remotes` directory can be given; the
+named file should be in the following format:
+
+ URL: one of the above URL format
+ Push: <refspec>
+ Pull: <refspec>
+
+Then such a short-hand is specified in place of
+<repository> without <refspec> parameters on the command
+line, <refspec> specified on `Push:` lines or `Pull:`
+lines are used for `git-push` and `git-fetch`/`git-pull`,
+respectively. Multiple `Push:` and and `Pull:` lines may
+be specified for additional branch mappings.
+
+The name of a file in `$GIT_DIR/branches` directory can be
+specified as an older notation short-hand; the named
+file should contain a single line, a URL in one of the
+above formats, optionally followed by a hash `#` and the
+name of remote head (URL fragment notation).
+`$GIT_DIR/branches/<remote>` file that stores a <url>
+without the fragment is equivalent to have this in the
+corresponding file in the `$GIT_DIR/remotes/` directory.
+
+ URL: <url>
+ Pull: refs/heads/master:<remote>
+
+while having `<url>#<head>` is equivalent to
+
+ URL: <url>
+ Pull: refs/heads/<head>:<remote>
projects / git.git / commitdiff