From 29f1431cd9ec079ebf2d1055c947a1883ddf0fa1 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 26 Oct 2006 08:47:29 +0000 Subject: [PATCH] Autogenerated HTML docs for v1.4.3.3-ge893f --- diff-format.txt | 76 +++++++++++++++++++++++++++++++---- everyday.html | 72 +++++++++------------------------ everyday.txt | 47 +++++++--------------- git-daemon.html | 8 ++-- git-daemon.txt | 6 +-- git-diff-files.html | 96 ++++++++++++++++++++++++++++++++++++++++---- git-diff-index.html | 96 ++++++++++++++++++++++++++++++++++++++++---- git-diff-stages.html | 96 ++++++++++++++++++++++++++++++++++++++++---- git-diff-tree.html | 96 ++++++++++++++++++++++++++++++++++++++++---- git-rev-parse.html | 46 +++++++++++++++++++-- git-rev-parse.txt | 25 ++++++++++-- 11 files changed, 522 insertions(+), 142 deletions(-) diff --git a/diff-format.txt b/diff-format.txt index 617d8f526..ed4ebcbab 100644 --- a/diff-format.txt +++ b/diff-format.txt @@ -156,31 +156,91 @@ to produce 'combined diff', which looks like this: ------------ 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 ,.. + mode ,.. + new file mode + deleted file mode , ++ +The `mode ,..` line appears only if at least one of +the 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 + 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: + + @@@ @@@ ++ +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 diff --git a/everyday.html b/everyday.html index 90ed11a19..e6a7289e1 100644 --- a/everyday.html +++ b/everyday.html @@ -263,37 +263,24 @@ div.exampleblock-content {
-

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.

In addition, [Individual Developer (Standalone)] commands are essential for anybody who makes a commit, even for somebody who works alone.

If you work with other people, you will need commands listed in -[Individual Developer (Participant)] section as well.

-

People who play [Integrator] role need to learn some more +the [Individual Developer (Participant)] section as well.

+

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

-

Everybody uses these commands to feed and care git repositories.

+

Everybody uses these commands to maintain git repositories.

  • @@ -303,13 +290,12 @@ repositories to support developers.

  • -git-fsck-objects(1) to validate the repository. +git-fsck-objects(1) to check the repository for errors.

  • -git-prune(1) to garbage collect cruft in the - repository. +git-prune(1) to remove unused objects in the repository.

  • @@ -370,8 +356,8 @@ $ git prune

    1. -pack all the objects reachable from the refs into one pack -and remove unneeded other packs +pack all the objects reachable from the refs into one pack, +then remove the other packs.

    @@ -396,12 +382,6 @@ following commands.

  • -git-whatchanged(1) to find out where things have - come from. -

    -
    • -
  • -

    git-checkout(1) and git-branch(1) to switch branches.

    @@ -447,11 +427,8 @@ following commands.

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
@@ -461,19 +438,10 @@ $ git add . (1)
 $ git commit -m 'import of frotz source tree.'
 $ git tag v2.43 (2)
-
    -
  1. -

    -add everything under the current directory. -

    -
    2. -
  2. -

    -make a lightweight, unannotated tag. -

    -
    3. -
-
+

+ +<1> add everything under the current directory. +<2> make a lightweight, unannotated tag.

+
Create a topic branch and develop.
@@ -610,7 +578,7 @@ $ cd my2.6 $ 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) @@ -928,7 +896,7 @@ Run git-daemon to serve /pub/scm from inetd. 
$ 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.

@@ -950,7 +918,7 @@ service git 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 } @@ -1067,7 +1035,7 @@ upload to public HTTP server hosted by your ISP. diff --git a/everyday.txt b/everyday.txt index b935c1808..278161f58 100644 --- a/everyday.txt +++ b/everyday.txt @@ -1,22 +1,7 @@ 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. - -<> commands are needed by people who has a +<> commands are needed by people who have a repository --- that is everybody, because every working tree of git is a repository. @@ -25,28 +10,27 @@ essential for anybody who makes a commit, even for somebody who works alone. If you work with other people, you will need commands listed in -<> section as well. +the <> section as well. -People who play <> role need to learn some more +People who play the <> role need to learn some more commands in addition to the above. <> 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. @@ -78,8 +62,8 @@ $ git repack -a -d <1> $ 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)]] @@ -93,9 +77,6 @@ following commands. * 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. @@ -120,7 +101,7 @@ following commands. 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 @@ -203,7 +184,7 @@ $ cd my2.6 $ 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> @@ -377,7 +358,7 @@ Run git-daemon to serve /pub/scm from inetd.:: ------------ $ 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. @@ -397,7 +378,7 @@ service git 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 } ------------ diff --git a/git-daemon.html b/git-daemon.html index 803be66f9..aeb9fe9da 100644 --- a/git-daemon.html +++ b/git-daemon.html @@ -537,8 +537,7 @@ git-daemon as inetd server 
        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
@@ -555,8 +554,7 @@ git-daemon as inetd server for virtual hosts 
        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
@@ -607,7 +605,7 @@ they correspond to these IP addresses.
diff --git a/git-daemon.txt b/git-daemon.txt index d562232e5..4b2ea2df3 100644 --- a/git-daemon.txt +++ b/git-daemon.txt @@ -165,8 +165,7 @@ git-daemon as inetd server:: + ------------------------------------------------ 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 ------------------------------------------------ @@ -179,8 +178,7 @@ git-daemon as inetd server for virtual hosts:: + ------------------------------------------------ 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 diff --git a/git-diff-files.html b/git-diff-files.html index 67bf25186..3f9d971ec 100644 --- a/git-diff-files.html +++ b/git-diff-files.html @@ -878,29 +878,109 @@ to produce combined diff, which looks like this:

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. +
  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. +
  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. +
  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.

    +
    5. +

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 file2, plus ++ to mean one line that was added does not appear @@ -927,7 +1007,7 @@ two unresolved merge parents with the working tree file

diff --git a/git-diff-index.html b/git-diff-index.html index 4118f5cc5..f86166f79 100644 --- a/git-diff-index.html +++ b/git-diff-index.html @@ -874,29 +874,109 @@ to produce combined diff, which looks like this:

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. +
  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. +
  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. +
  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.

    +
    5. +

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 file2, plus ++ to mean one line that was added does not appear @@ -1017,7 +1097,7 @@ always have the special all-zero sha1.

diff --git a/git-diff-stages.html b/git-diff-stages.html index 0f2faa3e9..e5d2eb278 100644 --- a/git-diff-stages.html +++ b/git-diff-stages.html @@ -852,29 +852,109 @@ to produce combined diff, which looks like this:

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. +
  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. +
  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. +
  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.

    +
    5. +

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 file2, plus ++ to mean one line that was added does not appear @@ -901,7 +981,7 @@ two unresolved merge parents with the working tree file

diff --git a/git-diff-tree.html b/git-diff-tree.html index e105e89ac..5069bafc9 100644 --- a/git-diff-tree.html +++ b/git-diff-tree.html @@ -1040,29 +1040,109 @@ to produce combined diff, which looks like this:

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. +
  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. +
  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. +
  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.

    +
    5. +

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 file2, plus ++ to mean one line that was added does not appear @@ -1089,7 +1169,7 @@ two unresolved merge parents with the working tree file

diff --git a/git-rev-parse.html b/git-rev-parse.html index 228603a99..987ebc956 100644 --- a/git-rev-parse.html +++ b/git-rev-parse.html @@ -489,7 +489,7 @@ The full SHA1 object name (40-byte hexadecimal string), or

  • 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.

  • @@ -498,11 +498,47 @@ 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:

    +
      +
    1. +

      +if $GIT_DIR/<name> exists, that is what you mean (this is usually + useful only for HEAD, FETCH_HEAD and MERGE_HEAD); +

      +
      2. +
    2. +

      +otherwise, $GIT_DIR/refs/<name> if exists; +

      +
      3. +
    3. +

      +otherwise, $GIT_DIR/refs/tags/<name> if exists; +

      +
      4. +
    4. +

      +otherwise, $GIT_DIR/refs/heads/<name> if exists; +

      +
      5. +
    5. +

      +otherwise, $GIT_DIR/refs/remotes/<name> if exists; +

      +
      6. +
    6. +

      +otherwise, $GIT_DIR/refs/remotes/<name>/HEAD if exists. +

      +
      7. +

  • -A suffix @ followed by a date specification enclosed in a brace +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 @@ -525,7 +561,9 @@ A suffix ^ to a revision parameter means the first parent of A suffix ~<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^^^ which is equivalent to rev^1^1^1. + equivalent to rev^^^ which is equivalent to + rev^1^1^1. See below for a illustration of + the usage of this form.

  • @@ -637,7 +675,7 @@ Junio C Hamano <junkio@cox.net>

    diff --git a/git-rev-parse.txt b/git-rev-parse.txt index 5d4257062..ed938aafb 100644 --- a/git-rev-parse.txt +++ b/git-rev-parse.txt @@ -122,14 +122,30 @@ blobs contained in a commit. 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 `` 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/` exists, that is what you mean (this is usually + useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`); + + . otherwise, `$GIT_DIR/refs/` if exists; + + . otherwise, `$GIT_DIR/refs/tags/` if exists; + + . otherwise, `$GIT_DIR/refs/heads/` if exists; + + . otherwise, `$GIT_DIR/refs/remotes/` if exists; + + . otherwise, `$GIT_DIR/refs/remotes//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 @@ -146,8 +162,9 @@ blobs contained in a commit. * A suffix '{tilde}' to a revision parameter means the commit object that is the 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 -- 2.26.2