------------
diff --combined describe.c
-@@@ +98,7 @@@
- return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
+index fabadb8,cc95eb0..4866510
+--- a/describe.c
++++ b/describe.c
+@@@ -98,20 -98,12 +98,20 @@@
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
-
+
- static void describe(char *arg)
-static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
{
- + unsigned char sha1[20];
- + struct commit *cmit;
+ + unsigned char sha1[20];
+ + struct commit *cmit;
+ struct commit_list *list;
+ static int initialized = 0;
+ struct commit_name *n;
+
+ + if (get_sha1(arg, sha1) < 0)
+ + usage(describe_usage);
+ + cmit = lookup_commit_reference(sha1);
+ + if (!cmit)
+ + usage(describe_usage);
+ +
+ if (!initialized) {
+ initialized = 1;
+ for_each_ref(get_name);
------------
+1. It is preceded with a "git diff" header, that looks like
+ this (when '-c' option is used):
+
+ diff --combined file
++
+or like this (when '--cc' option is used):
+
+ diff --c file
+
+2. It is followed by one or more extended header lines
+ (this example shows a merge with two parents):
+
+ index <hash>,<hash>..<hash>
+ mode <mode>,<mode>..<mode>
+ new file mode <mode>
+ deleted file mode <mode>,<mode>
++
+The `mode <mode>,<mode>..<mode>` line appears only if at least one of
+the <mode> is diferent from the rest. Extended headers with
+information about detected contents movement (renames and
+copying detection) are designed to work with diff of two
+<tree-ish> and are not used by combined diff format.
+
+3. It is followed by two-line from-file/to-file header
+
+ --- a/file
+ +++ b/file
++
+Similar to two-line header for traditional 'unified' diff
+format, `/dev/null` is used to signal created or deleted
+files.
+
+4. Chunk header format is modified to prevent people from
+ accidentally feeding it to `patch -p1`. Combined diff format
+ was created for review of merge commit changes, and was not
+ meant for apply. The change is similar to the change in the
+ extended 'index' header:
+
+ @@@ <from-file-range> <from-file-range> <to-file-range> @@@
++
+There are (number of parents + 1) `@` characters in the chunk
+header for combined diff format.
+
Unlike the traditional 'unified' diff format, which shows two
files A and B with a single column that has `-` (minus --
appears in A but removed in B), `+` (plus -- missing in A but
-added to B), or ` ` (space -- unchanged) prefix, this format
+added to B), or `" "` (space -- unchanged) prefix, this format
compares two or more files file1, file2,... with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
different from it.
A `-` character in the column N means that the line appears in
-fileN but it does not appear in the last file. A `+` character
+fileN but it does not appear in the result. A `+` character
in the column N means that the line appears in the last file,
-and fileN does not have that line.
+and fileN does not have that line (in other words, the line was
+added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
</div>\r
<div id="preamble">\r
<div class="sectionbody">\r
-<p>GIT suite has over 100 commands, and the manual page for each of\r
-them discusses what the command does and how it is used in\r
-detail, but until you know what command should be used in order\r
-to achieve what you want to do, you cannot tell which manual\r
-page to look at, and if you know that already you do not need\r
-the manual.</p>\r
-<p>Does that mean you need to know all of them before you can use\r
-git? Not at all. Depending on the role you play, the set of\r
-commands you need to know is slightly different, but in any case\r
-what you need to learn is far smaller than the full set of\r
-commands to carry out your day-to-day work. This document is to\r
-serve as a cheat-sheet and a set of pointers for people playing\r
-various roles.</p>\r
-<p><a href="#Basic Repository">[Basic Repository]</a> commands are needed by people who has a\r
+<p><a href="#Basic Repository">[Basic Repository]</a> commands are needed by people who have a\r
repository --- that is everybody, because every working tree of\r
git is a repository.</p>\r
<p>In addition, <a href="#Individual Developer (Standalone)">[Individual Developer (Standalone)]</a> commands are\r
essential for anybody who makes a commit, even for somebody who\r
works alone.</p>\r
<p>If you work with other people, you will need commands listed in\r
-<a href="#Individual Developer (Participant)">[Individual Developer (Participant)]</a> section as well.</p>\r
-<p>People who play <a href="#Integrator">[Integrator]</a> role need to learn some more\r
+
the <a href="#Individual Developer (Participant)">[Individual Developer (Participant)]</a> section as well.</p>
\r+<p>People who play
the <a href="#Integrator">[Integrator]</a> role need to learn some more
\r commands in addition to the above.</p>\r
<p><a href="#Repository Administration">[Repository Administration]</a> commands are for system\r
-administrators who are responsible to care and feed git\r
-repositories to support developers.</p>\r
+administrators who are responsible for the care and feeding\r
+of git repositories.</p>\r
</div>\r
</div>\r
<h2>Basic Repository<a id="Basic Repository"></a></h2>\r
<div class="sectionbody">\r
-<p>Everybody uses these commands to feed and care git repositories.</p>\r
+<p>Everybody uses these commands to maintain git repositories.</p>\r
<ul>\r
<li>\r
<p>\r
</li>\r
<li>\r
<p>\r
-<a href="git-fsck-objects.html">git-fsck-objects(1)</a> to validate the repository.\r
+<a href="git-fsck-objects.html">git-fsck-objects(1)</a> to check the repository for errors.\r
</p>\r
</li>\r
<li>\r
<p>\r
-<a href="git-prune.html">git-prune(1)</a> to garbage collect cruft in the\r
- repository.\r
+<a href="git-prune.html">git-prune(1)</a> to remove unused objects in the repository.\r
</p>\r
</li>\r
<li>\r
<ol>\r
<li>\r
<p>\r
-pack all the objects reachable from the refs into one pack\r
-and remove unneeded other packs\r
+pack all the objects reachable from the refs into one pack,\r
+then remove the other packs.\r
</p>\r
</li>\r
</ol>\r
</li>\r
<li>\r
<p>\r
-<a href="git-whatchanged.html">git-whatchanged(1)</a> to find out where things have\r
- come from.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
<a href="git-checkout.html">git-checkout(1)</a> and <a href="git-branch.html">git-branch(1)</a> to switch\r
branches.\r
</p>\r
</li>\r
</ul>\r
<h3>Examples</h3>\r
-<dl>\r
-<dt>\r
-Extract a tarball and create a working tree and a new repository to keep track of it.\r
-</dt>\r
-<dd>\r
+<p>Use a tarball as a starting point for a new repository:</p>\r
+<p>+</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ tar zxf frotz.tar.gz\r
$ git commit -m 'import of frotz source tree.'\r
$ git tag v2.43 <b>(2)</b></tt></pre>\r
</div></div>\r
-<ol>\r
-<li>\r
-<p>\r
-add everything under the current directory.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-make a lightweight, unannotated tag.\r
-</p>\r
-</li>\r
-</ol>\r
-</dd>\r
+<p>+\r
+<1> add everything under the current directory.\r
+<2> make a lightweight, unannotated tag.</p>\r
+<dl>\r
<dt>\r
Create a topic branch and develop.\r
</dt>\r
$ edit/compile/test; git commit -a -s <b>(1)</b>\r
$ git format-patch origin <b>(2)</b>\r
$ git pull <b>(3)</b>\r
-$ git whatchanged -p ORIG_HEAD.. arch/i386 include/asm-i386 <b>(4)</b>\r
+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <b>(4)</b>\r
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <b>(5)</b>\r
$ git reset --hard ORIG_HEAD <b>(6)</b>\r
$ git prune <b>(7)</b>\r
<div class="content">\r
<pre><tt>$ grep git /etc/inetd.conf\r
git stream tcp nowait nobody \\r
- /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm</tt></pre>\r
+ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm</tt></pre>\r
</div></div>\r
<p>The actual configuration line should be on one line.</p>\r
</dd>\r
wait = no\r
user = nobody\r
server = /usr/bin/git-daemon\r
- server_args = --inetd --syslog --export-all --base-path=/pub/scm\r
+ server_args = --inetd --export-all --base-path=/pub/scm\r
log_on_failure += USERID\r
}</tt></pre>\r
</div></div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:48 UTC\r
+Last updated 26-Oct-2006 08:47:21 UTC\r
</div>\r
</div>\r
</body>\r
Everyday GIT With 20 Commands Or So
===================================
-GIT suite has over 100 commands, and the manual page for each of
-them discusses what the command does and how it is used in
-detail, but until you know what command should be used in order
-to achieve what you want to do, you cannot tell which manual
-page to look at, and if you know that already you do not need
-the manual.
-
-Does that mean you need to know all of them before you can use
-git? Not at all. Depending on the role you play, the set of
-commands you need to know is slightly different, but in any case
-what you need to learn is far smaller than the full set of
-commands to carry out your day-to-day work. This document is to
-serve as a cheat-sheet and a set of pointers for people playing
-various roles.
-
-<<Basic Repository>> commands are needed by people who has a
+<<Basic Repository>> commands are needed by people who have a
repository --- that is everybody, because every working tree of
git is a repository.
works alone.
If you work with other people, you will need commands listed in
-<<Individual Developer (Participant)>> section as well.
+the <<Individual Developer (Participant)>> section as well.
-People who play <<Integrator>> role need to learn some more
+People who play the <<Integrator>> role need to learn some more
commands in addition to the above.
<<Repository Administration>> commands are for system
-administrators who are responsible to care and feed git
-repositories to support developers.
+administrators who are responsible for the care and feeding
+of git repositories.
Basic Repository[[Basic Repository]]
------------------------------------
-Everybody uses these commands to feed and care git repositories.
+Everybody uses these commands to maintain git repositories.
* gitlink:git-init-db[1] or gitlink:git-clone[1] to create a
new repository.
- * gitlink:git-fsck-objects[1] to validate the repository.
+ * gitlink:git-fsck-objects[1] to check the repository for errors.
- * gitlink:git-prune[1] to garbage collect cruft in the
- repository.
+ * gitlink:git-prune[1] to remove unused objects in the repository.
* gitlink:git-repack[1] to pack loose objects for efficiency.
$ git prune
------------
+
-<1> pack all the objects reachable from the refs into one pack
-and remove unneeded other packs
+<1> pack all the objects reachable from the refs into one pack,
+then remove the other packs.
Individual Developer (Standalone)[[Individual Developer (Standalone)]]
* gitlink:git-log[1] to see what happened.
- * gitlink:git-whatchanged[1] to find out where things have
- come from.
-
* gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
branches.
Examples
~~~~~~~~
-Extract a tarball and create a working tree and a new repository to keep track of it.::
+Use a tarball as a starting point for a new repository:
+
------------
$ tar zxf frotz.tar.gz
$ edit/compile/test; git commit -a -s <1>
$ git format-patch origin <2>
$ git pull <3>
-$ git whatchanged -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
$ git prune <7>
------------
$ grep git /etc/inetd.conf
git stream tcp nowait nobody \
- /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
+ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
------------
+
The actual configuration line should be on one line.
wait = no
user = nobody
server = /usr/bin/git-daemon
- server_args = --inetd --syslog --export-all --base-path=/pub/scm
+ server_args = --inetd --export-all --base-path=/pub/scm
log_on_failure += USERID
}
------------
<div class="listingblock">\r
<div class="content">\r
<pre><tt> git stream tcp nowait nobody /usr/bin/git-daemon\r
- git-daemon --inetd --verbose\r
- --syslog --export-all\r
+ git-daemon --inetd --verbose --export-all\r
/pub/foo /pub/bar</tt></pre>\r
</div></div>\r
</dd>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt> git stream tcp nowait nobody /usr/bin/git-daemon\r
- git-daemon --inetd --verbose\r
- --syslog --export-all\r
+ git-daemon --inetd --verbose --export-all\r
--interpolated-path=/pub/%H%D\r
/pub/www.example.org/software\r
/pub/www.example.com/software\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:40:59 UTC\r
+Last updated 26-Oct-2006 08:47:15 UTC\r
</div>\r
</div>\r
</body>\r
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git-daemon
- git-daemon --inetd --verbose
- --syslog --export-all
+ git-daemon --inetd --verbose --export-all
/pub/foo /pub/bar
------------------------------------------------
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git-daemon
- git-daemon --inetd --verbose
- --syslog --export-all
+ git-daemon --inetd --verbose --export-all
--interpolated-path=/pub/%H%D
/pub/www.example.org/software
/pub/www.example.com/software
<div class="listingblock">\r
<div class="content">\r
<pre><tt>diff --combined describe.c\r
-@@@ +98,7 @@@\r
- return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
+index fabadb8,cc95eb0..4866510\r
+--- a/describe.c\r
++++ b/describe.c\r
+@@@ -98,20 -98,12 +98,20 @@@\r
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
}\r
\r
- static void describe(char *arg)\r
-static void describe(struct commit *cmit, int last_one)\r
++static void describe(char *arg, int last_one)\r
{\r
- + unsigned char sha1[20];\r
- + struct commit *cmit;</tt></pre>\r
+ + unsigned char sha1[20];\r
+ + struct commit *cmit;\r
+ struct commit_list *list;\r
+ static int initialized = 0;\r
+ struct commit_name *n;\r
+\r
+ + if (get_sha1(arg, sha1) < 0)\r
+ + usage(describe_usage);\r
+ + cmit = lookup_commit_reference(sha1);\r
+ + if (!cmit)\r
+ + usage(describe_usage);\r
+ +\r
+ if (!initialized) {\r
+ initialized = 1;\r
+ for_each_ref(get_name);</tt></pre>\r
</div></div>\r
+<ol>\r
+<li>\r
+<p>\r
+It is preceded with a "git diff" header, that looks like\r
+ this (when <em>-c</em> option is used):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --combined file</tt></pre>\r
+</div></div>\r
+<p>or like this (when <em>--cc</em> option is used):</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --c file</tt></pre>\r
+</div></div>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by one or more extended header lines\r
+ (this example shows a merge with two parents):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>index <hash>,<hash>..<hash>\r
+mode <mode>,<mode>..<mode>\r
+new file mode <mode>\r
+deleted file mode <mode>,<mode></tt></pre>\r
+</div></div>\r
+<p>The <tt>mode <mode>,<mode>..<mode></tt> line appears only if at least one of\r
+the <mode> is diferent from the rest. Extended headers with\r
+information about detected contents movement (renames and\r
+copying detection) are designed to work with diff of two\r
+<tree-ish> and are not used by combined diff format.</p>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by two-line from-file/to-file header\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>--- a/file\r
++++ b/file</tt></pre>\r
+</div></div>\r
+<p>Similar to two-line header for traditional <em>unified</em> diff\r
+format, <tt>/dev/null</tt> is used to signal created or deleted\r
+files.</p>\r
+</li>\r
+<li>\r
+<p>\r
+Chunk header format is modified to prevent people from\r
+ accidentally feeding it to <tt>patch -p1</tt>. Combined diff format\r
+ was created for review of merge commit changes, and was not\r
+ meant for apply. The change is similar to the change in the\r
+ extended <em>index</em> header:\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>@@@ <from-file-range> <from-file-range> <to-file-range> @@@</tt></pre>\r
+</div></div>\r
+<p>There are (number of parents + 1) <tt>@</tt> characters in the chunk\r
+header for combined diff format.</p>\r
+</li>\r
+</ol>\r
<p>Unlike the traditional <em>unified</em> diff format, which shows two\r
files A and B with a single column that has <tt>-</tt> (minus —\r
appears in A but removed in B), <tt>+</tt> (plus — missing in A but\r
-added to B), or <tt> </tt> (space — unchanged) prefix, this format\r
+added to B), or <tt>" "</tt> (space — unchanged) prefix, this format\r
compares two or more files file1, file2,… with one file X, and\r
shows how X differs from each of fileN. One column for each of\r
fileN is prepended to the output line to note how X's line is\r
different from it.</p>\r
<p>A <tt>-</tt> character in the column N means that the line appears in\r
-fileN but it does not appear in the last file. A <tt>+</tt> character\r
+fileN but it does not appear in the result. A <tt>+</tt> character\r
in the column N means that the line appears in the last file,\r
-and fileN does not have that line.</p>\r
+and fileN does not have that line (in other words, the line was\r
+added, from the point of view of that parent).</p>\r
<p>In the above example output, the function signature was changed\r
from both files (hence two <tt>-</tt> removals from both file1 and\r
file2, plus <tt>++</tt> to mean one line that was added does not appear\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Oct-2006 05:58:36 UTC\r
+Last updated 26-Oct-2006 08:47:16 UTC\r
</div>\r
</div>\r
</body>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>diff --combined describe.c\r
-@@@ +98,7 @@@\r
- return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
+index fabadb8,cc95eb0..4866510\r
+--- a/describe.c\r
++++ b/describe.c\r
+@@@ -98,20 -98,12 +98,20 @@@\r
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
}\r
\r
- static void describe(char *arg)\r
-static void describe(struct commit *cmit, int last_one)\r
++static void describe(char *arg, int last_one)\r
{\r
- + unsigned char sha1[20];\r
- + struct commit *cmit;</tt></pre>\r
+ + unsigned char sha1[20];\r
+ + struct commit *cmit;\r
+ struct commit_list *list;\r
+ static int initialized = 0;\r
+ struct commit_name *n;\r
+\r
+ + if (get_sha1(arg, sha1) < 0)\r
+ + usage(describe_usage);\r
+ + cmit = lookup_commit_reference(sha1);\r
+ + if (!cmit)\r
+ + usage(describe_usage);\r
+ +\r
+ if (!initialized) {\r
+ initialized = 1;\r
+ for_each_ref(get_name);</tt></pre>\r
+</div></div>\r
+<ol>\r
+<li>\r
+<p>\r
+It is preceded with a "git diff" header, that looks like\r
+ this (when <em>-c</em> option is used):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --combined file</tt></pre>\r
+</div></div>\r
+<p>or like this (when <em>--cc</em> option is used):</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --c file</tt></pre>\r
+</div></div>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by one or more extended header lines\r
+ (this example shows a merge with two parents):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>index <hash>,<hash>..<hash>\r
+mode <mode>,<mode>..<mode>\r
+new file mode <mode>\r
+deleted file mode <mode>,<mode></tt></pre>\r
+</div></div>\r
+<p>The <tt>mode <mode>,<mode>..<mode></tt> line appears only if at least one of\r
+the <mode> is diferent from the rest. Extended headers with\r
+information about detected contents movement (renames and\r
+copying detection) are designed to work with diff of two\r
+<tree-ish> and are not used by combined diff format.</p>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by two-line from-file/to-file header\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>--- a/file\r
++++ b/file</tt></pre>\r
</div></div>\r
+<p>Similar to two-line header for traditional <em>unified</em> diff\r
+format, <tt>/dev/null</tt> is used to signal created or deleted\r
+files.</p>\r
+</li>\r
+<li>\r
+<p>\r
+Chunk header format is modified to prevent people from\r
+ accidentally feeding it to <tt>patch -p1</tt>. Combined diff format\r
+ was created for review of merge commit changes, and was not\r
+ meant for apply. The change is similar to the change in the\r
+ extended <em>index</em> header:\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>@@@ <from-file-range> <from-file-range> <to-file-range> @@@</tt></pre>\r
+</div></div>\r
+<p>There are (number of parents + 1) <tt>@</tt> characters in the chunk\r
+header for combined diff format.</p>\r
+</li>\r
+</ol>\r
<p>Unlike the traditional <em>unified</em> diff format, which shows two\r
files A and B with a single column that has <tt>-</tt> (minus —\r
appears in A but removed in B), <tt>+</tt> (plus — missing in A but\r
-added to B), or <tt> </tt> (space — unchanged) prefix, this format\r
+added to B), or <tt>" "</tt> (space — unchanged) prefix, this format\r
compares two or more files file1, file2,… with one file X, and\r
shows how X differs from each of fileN. One column for each of\r
fileN is prepended to the output line to note how X's line is\r
different from it.</p>\r
<p>A <tt>-</tt> character in the column N means that the line appears in\r
-fileN but it does not appear in the last file. A <tt>+</tt> character\r
+fileN but it does not appear in the result. A <tt>+</tt> character\r
in the column N means that the line appears in the last file,\r
-and fileN does not have that line.</p>\r
+and fileN does not have that line (in other words, the line was\r
+added, from the point of view of that parent).</p>\r
<p>In the above example output, the function signature was changed\r
from both files (hence two <tt>-</tt> removals from both file1 and\r
file2, plus <tt>++</tt> to mean one line that was added does not appear\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Oct-2006 05:58:37 UTC\r
+Last updated 26-Oct-2006 08:47:17 UTC\r
</div>\r
</div>\r
</body>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>diff --combined describe.c\r
-@@@ +98,7 @@@\r
- return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
+index fabadb8,cc95eb0..4866510\r
+--- a/describe.c\r
++++ b/describe.c\r
+@@@ -98,20 -98,12 +98,20 @@@\r
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
}\r
\r
- static void describe(char *arg)\r
-static void describe(struct commit *cmit, int last_one)\r
++static void describe(char *arg, int last_one)\r
{\r
- + unsigned char sha1[20];\r
- + struct commit *cmit;</tt></pre>\r
+ + unsigned char sha1[20];\r
+ + struct commit *cmit;\r
+ struct commit_list *list;\r
+ static int initialized = 0;\r
+ struct commit_name *n;\r
+\r
+ + if (get_sha1(arg, sha1) < 0)\r
+ + usage(describe_usage);\r
+ + cmit = lookup_commit_reference(sha1);\r
+ + if (!cmit)\r
+ + usage(describe_usage);\r
+ +\r
+ if (!initialized) {\r
+ initialized = 1;\r
+ for_each_ref(get_name);</tt></pre>\r
</div></div>\r
+<ol>\r
+<li>\r
+<p>\r
+It is preceded with a "git diff" header, that looks like\r
+ this (when <em>-c</em> option is used):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --combined file</tt></pre>\r
+</div></div>\r
+<p>or like this (when <em>--cc</em> option is used):</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --c file</tt></pre>\r
+</div></div>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by one or more extended header lines\r
+ (this example shows a merge with two parents):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>index <hash>,<hash>..<hash>\r
+mode <mode>,<mode>..<mode>\r
+new file mode <mode>\r
+deleted file mode <mode>,<mode></tt></pre>\r
+</div></div>\r
+<p>The <tt>mode <mode>,<mode>..<mode></tt> line appears only if at least one of\r
+the <mode> is diferent from the rest. Extended headers with\r
+information about detected contents movement (renames and\r
+copying detection) are designed to work with diff of two\r
+<tree-ish> and are not used by combined diff format.</p>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by two-line from-file/to-file header\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>--- a/file\r
++++ b/file</tt></pre>\r
+</div></div>\r
+<p>Similar to two-line header for traditional <em>unified</em> diff\r
+format, <tt>/dev/null</tt> is used to signal created or deleted\r
+files.</p>\r
+</li>\r
+<li>\r
+<p>\r
+Chunk header format is modified to prevent people from\r
+ accidentally feeding it to <tt>patch -p1</tt>. Combined diff format\r
+ was created for review of merge commit changes, and was not\r
+ meant for apply. The change is similar to the change in the\r
+ extended <em>index</em> header:\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>@@@ <from-file-range> <from-file-range> <to-file-range> @@@</tt></pre>\r
+</div></div>\r
+<p>There are (number of parents + 1) <tt>@</tt> characters in the chunk\r
+header for combined diff format.</p>\r
+</li>\r
+</ol>\r
<p>Unlike the traditional <em>unified</em> diff format, which shows two\r
files A and B with a single column that has <tt>-</tt> (minus —\r
appears in A but removed in B), <tt>+</tt> (plus — missing in A but\r
-added to B), or <tt> </tt> (space — unchanged) prefix, this format\r
+added to B), or <tt>" "</tt> (space — unchanged) prefix, this format\r
compares two or more files file1, file2,… with one file X, and\r
shows how X differs from each of fileN. One column for each of\r
fileN is prepended to the output line to note how X's line is\r
different from it.</p>\r
<p>A <tt>-</tt> character in the column N means that the line appears in\r
-fileN but it does not appear in the last file. A <tt>+</tt> character\r
+fileN but it does not appear in the result. A <tt>+</tt> character\r
in the column N means that the line appears in the last file,\r
-and fileN does not have that line.</p>\r
+and fileN does not have that line (in other words, the line was\r
+added, from the point of view of that parent).</p>\r
<p>In the above example output, the function signature was changed\r
from both files (hence two <tt>-</tt> removals from both file1 and\r
file2, plus <tt>++</tt> to mean one line that was added does not appear\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Oct-2006 05:58:38 UTC\r
+Last updated 26-Oct-2006 08:47:18 UTC\r
</div>\r
</div>\r
</body>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>diff --combined describe.c\r
-@@@ +98,7 @@@\r
- return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
+index fabadb8,cc95eb0..4866510\r
+--- a/describe.c\r
++++ b/describe.c\r
+@@@ -98,20 -98,12 +98,20 @@@\r
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;\r
}\r
\r
- static void describe(char *arg)\r
-static void describe(struct commit *cmit, int last_one)\r
++static void describe(char *arg, int last_one)\r
{\r
- + unsigned char sha1[20];\r
- + struct commit *cmit;</tt></pre>\r
+ + unsigned char sha1[20];\r
+ + struct commit *cmit;\r
+ struct commit_list *list;\r
+ static int initialized = 0;\r
+ struct commit_name *n;\r
+\r
+ + if (get_sha1(arg, sha1) < 0)\r
+ + usage(describe_usage);\r
+ + cmit = lookup_commit_reference(sha1);\r
+ + if (!cmit)\r
+ + usage(describe_usage);\r
+ +\r
+ if (!initialized) {\r
+ initialized = 1;\r
+ for_each_ref(get_name);</tt></pre>\r
+</div></div>\r
+<ol>\r
+<li>\r
+<p>\r
+It is preceded with a "git diff" header, that looks like\r
+ this (when <em>-c</em> option is used):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --combined file</tt></pre>\r
+</div></div>\r
+<p>or like this (when <em>--cc</em> option is used):</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>diff --c file</tt></pre>\r
+</div></div>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by one or more extended header lines\r
+ (this example shows a merge with two parents):\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>index <hash>,<hash>..<hash>\r
+mode <mode>,<mode>..<mode>\r
+new file mode <mode>\r
+deleted file mode <mode>,<mode></tt></pre>\r
+</div></div>\r
+<p>The <tt>mode <mode>,<mode>..<mode></tt> line appears only if at least one of\r
+the <mode> is diferent from the rest. Extended headers with\r
+information about detected contents movement (renames and\r
+copying detection) are designed to work with diff of two\r
+<tree-ish> and are not used by combined diff format.</p>\r
+</li>\r
+<li>\r
+<p>\r
+It is followed by two-line from-file/to-file header\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>--- a/file\r
++++ b/file</tt></pre>\r
</div></div>\r
+<p>Similar to two-line header for traditional <em>unified</em> diff\r
+format, <tt>/dev/null</tt> is used to signal created or deleted\r
+files.</p>\r
+</li>\r
+<li>\r
+<p>\r
+Chunk header format is modified to prevent people from\r
+ accidentally feeding it to <tt>patch -p1</tt>. Combined diff format\r
+ was created for review of merge commit changes, and was not\r
+ meant for apply. The change is similar to the change in the\r
+ extended <em>index</em> header:\r
+</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>@@@ <from-file-range> <from-file-range> <to-file-range> @@@</tt></pre>\r
+</div></div>\r
+<p>There are (number of parents + 1) <tt>@</tt> characters in the chunk\r
+header for combined diff format.</p>\r
+</li>\r
+</ol>\r
<p>Unlike the traditional <em>unified</em> diff format, which shows two\r
files A and B with a single column that has <tt>-</tt> (minus —\r
appears in A but removed in B), <tt>+</tt> (plus — missing in A but\r
-added to B), or <tt> </tt> (space — unchanged) prefix, this format\r
+added to B), or <tt>" "</tt> (space — unchanged) prefix, this format\r
compares two or more files file1, file2,… with one file X, and\r
shows how X differs from each of fileN. One column for each of\r
fileN is prepended to the output line to note how X's line is\r
different from it.</p>\r
<p>A <tt>-</tt> character in the column N means that the line appears in\r
-fileN but it does not appear in the last file. A <tt>+</tt> character\r
+fileN but it does not appear in the result. A <tt>+</tt> character\r
in the column N means that the line appears in the last file,\r
-and fileN does not have that line.</p>\r
+and fileN does not have that line (in other words, the line was\r
+added, from the point of view of that parent).</p>\r
<p>In the above example output, the function signature was changed\r
from both files (hence two <tt>-</tt> removals from both file1 and\r
file2, plus <tt>++</tt> to mean one line that was added does not appear\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Oct-2006 05:58:39 UTC\r
+Last updated 26-Oct-2006 08:47:19 UTC\r
</div>\r
</div>\r
</body>\r
<li>\r
<p>\r
An output from <tt>git-describe</tt>; i.e. a closest tag, followed by a\r
- dash, a <em>g</em>, and an abbreviated object name.\r
+ dash, a <tt>g</tt>, and an abbreviated object name.\r
</p>\r
</li>\r
<li>\r
object referenced by $GIT_DIR/refs/heads/master. If you\r
happen to have both heads/master and tags/master, you can\r
explicitly say <em>heads/master</em> to tell git which one you mean.\r
+ When ambiguous, a <tt><name></tt> is disambiguated by taking the\r
+ first match in the following rules:\r
</p>\r
+<ol>\r
+<li>\r
+<p>\r
+if <tt>$GIT_DIR/<name></tt> exists, that is what you mean (this is usually\r
+ useful only for <tt>HEAD</tt>, <tt>FETCH_HEAD</tt> and <tt>MERGE_HEAD</tt>);\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+otherwise, <tt>$GIT_DIR/refs/<name></tt> if exists;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+otherwise, <tt>$GIT_DIR/refs/tags/<name></tt> if exists;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+otherwise, <tt>$GIT_DIR/refs/heads/<name></tt> if exists;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+otherwise, <tt>$GIT_DIR/refs/remotes/<name></tt> if exists;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+otherwise, <tt>$GIT_DIR/refs/remotes/<name>/HEAD</tt> if exists.\r
+</p>\r
+</li>\r
+</ol>\r
</li>\r
<li>\r
<p>\r
-A suffix <em>@</em> followed by a date specification enclosed in a brace\r
+A ref followed by the suffix <em>@</em> with a date specification\r
+ enclosed in a brace\r
pair (e.g. <em>{yesterday}</em>, <em>{1 month 2 weeks 3 days 1 hour 1\r
second ago}</em> or <em>{1979-02-26 18:30:00}</em>) to specify the value\r
of the ref at a prior point in time. This suffix may only be\r
A suffix <em>~<n></em> to a revision parameter means the commit\r
object that is the <n>th generation grand-parent of the named\r
commit object, following only the first parent. I.e. rev~3 is\r
- equivalent to rev^^^ which is equivalent to rev^1^1^1.\r
+ equivalent to rev^^^ which is equivalent to\r
+ rev^1^1^1. See below for a illustration of\r
+ the usage of this form.\r
</p>\r
</li>\r
<li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Oct-2006 05:58:41 UTC\r
+Last updated 26-Oct-2006 08:47:20 UTC\r
</div>\r
</div>\r
</body>\r
your repository whose object name starts with dae86e.
* An output from `git-describe`; i.e. a closest tag, followed by a
- dash, a 'g', and an abbreviated object name.
+ dash, a `g`, and an abbreviated object name.
* A symbolic ref name. E.g. 'master' typically means the commit
object referenced by $GIT_DIR/refs/heads/master. If you
happen to have both heads/master and tags/master, you can
explicitly say 'heads/master' to tell git which one you mean.
+ When ambiguous, a `<name>` is disambiguated by taking the
+ first match in the following rules:
-* A suffix '@' followed by a date specification enclosed in a brace
+ . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
+ useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);
+
+ . otherwise, `$GIT_DIR/refs/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/tags/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/heads/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists.
+
+* A ref followed by the suffix '@' with a date specification
+ enclosed in a brace
pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
of the ref at a prior point in time. This suffix may only be
* A suffix '{tilde}<n>' to a revision parameter means the commit
object that is the <n>th generation grand-parent of the named
commit object, following only the first parent. I.e. rev~3 is
- equivalent to rev{caret}{caret}{caret} which is equivalent to\
- rev{caret}1{caret}1{caret}1.
+ equivalent to rev{caret}{caret}{caret} which is equivalent to
+ rev{caret}1{caret}1{caret}1. See below for a illustration of
+ the usage of this form.
* A suffix '{caret}' followed by an object type name enclosed in
brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
projects / git.git / commitdiff