- "git log" learned --log-size to show the number of bytes in
the log message part of the output to help qgit.
+ - "git log --name-status" does not require you to give "-r" anymore.
+ As a general rule, Porcelain commands should recurse when showing
+ diff.
+
+ - "git format-patch --root A" can be used to format everything
+ since the beginning up to A. This was supported with
+ "git format-patch --root A A" for a long time, but was not
+ properly documented.
+
- "git svn dcommit" retains local merge information.
- "git svnimport" allows an empty string to be specified as the
when switching branches that have differences in only a
handful paths.
- - "git commit paths..." has also been optimized.
-
+ - "git add paths..." and "git commit paths..." has also been
+ heavily optimized.
Fixes since v1.5.2
------------------
- "git-write-tree" had a bad interaction with racy-git avoidance and
gitattributes mechanisms.
+ - "git --bare command" overrode existing GIT_DIR setting and always
+ made it treat the current working directory as GIT_DIR.
+
--
exec >/var/tmp/1
-O=v1.5.3-rc6-47-ge92ea62
+O=v1.5.3-rc7
echo O=`git describe refs/heads/master`
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
<p>The <em>git add</em> command will not add ignored files by default. If any\r
ignored files were explicitly specified on the command line, <em>git add</em>\r
will fail with a list of ignored files. Ignored files reached by\r
-directory recursion or filename globbing will be silently ignored.\r
-The <em>add</em> command can be used to add ignored files with the <tt>-f</tt>\r
-(force) option.</p>\r
+directory recursion or filename globbing performed by Git (quote your\r
+globs before the shell) will be silently ignored. The <em>add</em> command can\r
+be used to add ignored files with the <tt>-f</tt> (force) option.</p>\r
<p>Please see <a href="git-commit.html">git-commit(1)</a> for alternative ways to add content to a\r
commit.</p>\r
</div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 26-Aug-2007 22:09:43 UTC\r
+Last updated 29-Aug-2007 07:30:53 UTC\r
</div>\r
</div>\r
</body>\r
The 'git add' command will not add ignored files by default. If any
ignored files were explicitly specified on the command line, 'git add'
will fail with a list of ignored files. Ignored files reached by
-directory recursion or filename globbing will be silently ignored.
-The 'add' command can be used to add ignored files with the `-f`
-(force) option.
+directory recursion or filename globbing performed by Git (quote your
+globs before the shell) will be silently ignored. The 'add' command can
+be used to add ignored files with the `-f` (force) option.
Please see gitlink:git-commit[1] for alternative ways to add content to a
commit.
</p>\r
</dd>\r
<dt>\r
-<em>git-diff</em> [--options] <commit>…<commit> [--] [<path>…]\r
+<em>git-diff</em> [--options] <commit>...<commit> [--] [<path>…]\r
</dt>\r
<dd>\r
<p>\r
This form is to view the changes on the branch containing\r
and up to the second <commit>, starting at a common ancestor\r
- of both <commit>. "git-diff A…B" is equivalent to\r
+ of both <commit>. "git-diff A...B" is equivalent to\r
"git-diff $(git-merge-base A B) B". You can omit any one\r
of <commit>, which has the same effect as using HEAD instead.\r
</p>\r
</dd>\r
</dl>\r
<p>Just in case if you are doing something exotic, it should be\r
-noted that all of the <commit> in the above description can be\r
-any <tree-ish>.</p>\r
+noted that all of the <commit> in the above description, except\r
+for the last two forms that use ".." notations, can be any\r
+<tree-ish>.</p>\r
<p>For a more complete list of ways to spell <commit>, see\r
"SPECIFYING REVISIONS" section in <a href="git-rev-parse.html">git-rev-parse(1)</a>.\r
However, "diff" is about comparing two _endpoints_, not ranges,\r
and the range notations ("<commit>..<commit>" and\r
-"<commit>…<commit>") do not mean a range as defined in the\r
+"<commit>...<commit>") do not mean a range as defined in the\r
"SPECIFYING RANGES" section in <a href="git-rev-parse.html">git-rev-parse(1)</a>.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 28-Aug-2007 06:25:09 UTC\r
+Last updated 29-Aug-2007 07:30:53 UTC\r
</div>\r
</div>\r
</body>\r
one side is omitted, it will have the same effect as
using HEAD instead.
-'git-diff' [--options] <commit>...<commit> [--] [<path>...]::
+'git-diff' [--options] <commit>\...<commit> [--] [<path>...]::
This form is to view the changes on the branch containing
and up to the second <commit>, starting at a common ancestor
- of both <commit>. "git-diff A...B" is equivalent to
+ of both <commit>. "git-diff A\...B" is equivalent to
"git-diff $(git-merge-base A B) B". You can omit any one
of <commit>, which has the same effect as using HEAD instead.
Just in case if you are doing something exotic, it should be
-noted that all of the <commit> in the above description can be
-any <tree-ish>.
+noted that all of the <commit> in the above description, except
+for the last two forms that use ".." notations, can be any
+<tree-ish>.
For a more complete list of ways to spell <commit>, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
However, "diff" is about comparing two _endpoints_, not ranges,
and the range notations ("<commit>..<commit>" and
-"<commit>...<commit>") do not mean a range as defined in the
+"<commit>\...<commit>") do not mean a range as defined in the
"SPECIFYING RANGES" section in gitlink:git-rev-parse[1].
OPTIONS
[--in-reply-to=Message-Id] [--suffix=.<sfx>]\r
[--ignore-if-in-upstream]\r
[--subject-prefix=Subject-Prefix]\r
- <since>[..<until>]</div></div>\r
+ [ <since> | <revision range> ]</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
-<p>Prepare each commit between <since> and <until> with its patch in\r
+<p>Prepare each commit with its patch in\r
one file per commit, formatted to resemble UNIX mailbox format.\r
-If ..<until> is not specified, the head of the current working\r
-tree is implied. For a more complete list of ways to spell\r
-<since> and <until>, see "SPECIFYING REVISIONS" section in\r
-<a href="git-rev-parse.html">git-rev-parse(1)</a>.</p>\r
-<p>The output of this command is convenient for e-mail submission or\r
+The output of this command is convenient for e-mail submission or\r
for use with <a href="git-am.html">git-am(1)</a>.</p>\r
+<p>There are two ways to specify which commits to operate on.</p>\r
+<ol>\r
+<li>\r
+<p>\r
+A single commit, <since>, specifies that the commits leading\r
+ to the tip of the current branch that are not in the history\r
+ that leads to the <since> to be output.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+Generic <revision range> expression (see "SPECIFYING\r
+ REVISIONS" section in <a href="git-rev-parse.html">git-rev-parse(1)</a>) means the\r
+ commits in the specified range.\r
+</p>\r
+</li>\r
+</ol>\r
+<p>A single commit, when interpreted as a <revision range>\r
+expression, means "everything that leads to that commit", but\r
+if you write <em>git format-patch <commit></em>, the previous rule\r
+applies to that command line and you do not get "everything\r
+since the beginning of the time". If you want to format\r
+everything since project inception to one commit, say "git\r
+format-patch --root <commit>" to make it clear that it is the\r
+latter case.</p>\r
<p>By default, each output file is numbered sequentially from 1, and uses the\r
first line of the commit message (massaged for pathname safety) as\r
the filename. With the --numbered-files option, the output file names\r
</p>\r
</dd>\r
<dt>\r
+git-format-patch --root origin\r
+</dt>\r
+<dd>\r
+<p>\r
+ Extract all commits which that leads to <em>origin</em> since the\r
+ inception of the project.\r
+</p>\r
+</dd>\r
+<dt>\r
git-format-patch -M -B origin\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 25-Aug-2007 03:53:09 UTC\r
+Last updated 29-Aug-2007 07:30:57 UTC\r
</div>\r
</div>\r
</body>\r
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
[--ignore-if-in-upstream]
[--subject-prefix=Subject-Prefix]
- <since>[..<until>]
+ [ <since> | <revision range> ]
DESCRIPTION
-----------
-Prepare each commit between <since> and <until> with its patch in
+Prepare each commit with its patch in
one file per commit, formatted to resemble UNIX mailbox format.
-If ..<until> is not specified, the head of the current working
-tree is implied. For a more complete list of ways to spell
-<since> and <until>, see "SPECIFYING REVISIONS" section in
-gitlink:git-rev-parse[1].
-
The output of this command is convenient for e-mail submission or
for use with gitlink:git-am[1].
+There are two ways to specify which commits to operate on.
+
+1. A single commit, <since>, specifies that the commits leading
+ to the tip of the current branch that are not in the history
+ that leads to the <since> to be output.
+
+2. Generic <revision range> expression (see "SPECIFYING
+ REVISIONS" section in gitlink:git-rev-parse[1]) means the
+ commits in the specified range.
+
+A single commit, when interpreted as a <revision range>
+expression, means "everything that leads to that commit", but
+if you write 'git format-patch <commit>', the previous rule
+applies to that command line and you do not get "everything
+since the beginning of the time". If you want to format
+everything since project inception to one commit, say "git
+format-patch \--root <commit>" to make it clear that it is the
+latter case.
+
By default, each output file is numbered sequentially from 1, and uses the
first line of the commit message (massaged for pathname safety) as
the filename. With the --numbered-files option, the output file names
not in the origin branch. For each commit a separate file
is created in the current directory.
+git-format-patch \--root origin::
+ Extract all commits which that leads to 'origin' since the
+ inception of the project.
+
git-format-patch -M -B origin::
The same as the previous one. Additionally, it detects
and handles renames and complete rewrites intelligently to
</p>\r
</dd>\r
<dt>\r
-git log -r --name-status release..test\r
+git log --name-status release..test\r
</dt>\r
<dd>\r
<p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 21-Aug-2007 02:20:18 UTC\r
+Last updated 29-Aug-2007 07:30:56 UTC\r
</div>\r
</div>\r
</body>\r
The "--" is necessary to avoid confusion with the *branch* named
'gitk'
-git log -r --name-status release..test::
+git log --name-status release..test::
Show the commits that are in the "test" branch but not yet
in the "release" branch, along with the list of paths
trunk = trunk/project-a:refs/remotes/project-a/trunk</tt></pre>\r
</div></div>\r
<p>Keep in mind that the <em><strong></em> (asterisk) wildcard of the local ref\r
-(left of the <em>:</em>) *must</strong> be the farthest right path component;\r
+(right of the <em>:</em>) *must</strong> be the farthest right path component;\r
however the remote wildcard may be anywhere as long as it's own\r
independent path component (surrounded by <em>/</em> or EOL). This\r
type of configuration is not automatically created by <em>init</em> and\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 25-Aug-2007 03:53:14 UTC\r
+Last updated 29-Aug-2007 07:30:59 UTC\r
</div>\r
</div>\r
</body>\r
------------------------------------------------------------------------
Keep in mind that the '*' (asterisk) wildcard of the local ref
-(left of the ':') *must* be the farthest right path component;
+(right of the ':') *must* be the farthest right path component;
however the remote wildcard may be anywhere as long as it's own
independent path component (surrounded by '/' or EOL). This
type of configuration is not automatically created by 'init' and
echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"</p></div><p>and then he just cut-and-pastes the output commands after verifying that
they look OK.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="Finding-comments-with-given-content"></a>Finding commits referencing a file with given content</h3></div></div></div><p>Somebody hands you a copy of a file, and asks which commits modified a
file such that it contained the given content either before or after the
-commit. You can find out with this:</p><div class="literallayout"><p>$ git log --raw -r --abbrev=40 --pretty=oneline -- filename |<br>
+commit. You can find out with this:</p><div class="literallayout"><p>$ git log --raw --abbrev=40 --pretty=oneline -- filename |<br>
grep -B 1 `git hash-object filename`</p></div><p>Figuring out why this works is left as an exercise to the (advanced)
student. The <a href="git-log.html" target="_top">git-log(1)</a>, <a href="git-diff-tree.html" target="_top">git-diff-tree(1)</a>, and
<a href="git-hash-object.html" target="_top">git-hash-object(1)</a> man pages may prove helpful.</p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="Developing-with-git"></a>Chapter 3. Developing with git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="telling-git-your-name"></a>Telling git your name</h2></div></div></div><p>Before creating any commits, you should introduce yourself to git. The
commit. You can find out with this:
-------------------------------------------------
-$ git log --raw -r --abbrev=40 --pretty=oneline -- filename |
+$ git log --raw --abbrev=40 --pretty=oneline -- filename |
grep -B 1 `git hash-object filename`
-------------------------------------------------