From: Junio C Hamano Date: Sat, 3 Feb 2007 08:07:35 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.0-rc3-22-g5057 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=8a66a65638e314180d1e8aa89b35544b1800dc87;p=git.git Autogenerated HTML docs for v1.5.0-rc3-22-g5057 --- diff --git a/core-tutorial.html b/core-tutorial.html index fd0e670fb..c8ccee785 100644 --- a/core-tutorial.html +++ b/core-tutorial.html @@ -1704,8 +1704,8 @@ repositories every once in a while.

Although git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There -is a nice illustration (page 17, "Merges to Mainline") in Randy -Dunlap's presentation (http://tinyurl.com/a2jdg).

+is a nice illustration (page 17, "Merges to Mainline") in +Randy Dunlap's presentation.

It should be stressed that this hierarchy is purely informal. There is nothing fundamental in git that enforces the "chain of patch flow" this hierarchy implies. You do not have to pull @@ -1969,7 +1969,7 @@ to follow, not easier.

diff --git a/core-tutorial.txt b/core-tutorial.txt index 1cd834b0f..9c28bea62 100644 --- a/core-tutorial.txt +++ b/core-tutorial.txt @@ -1469,8 +1469,8 @@ Working with Others Although git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There -is a nice illustration (page 17, "Merges to Mainline") in Randy -Dunlap's presentation (`http://tinyurl.com/a2jdg`). +is a nice illustration (page 17, "Merges to Mainline") in +link:http://tinyurl.com/a2jdg[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. There is nothing fundamental in git that enforces the "chain of diff --git a/hooks.html b/hooks.html index e1cc5d64e..20c85a952 100644 --- a/hooks.html +++ b/hooks.html @@ -336,8 +336,6 @@ the commit after inspecting the message file.

parameter, and is invoked after a commit is made.

This hook is meant primarily for notification, and cannot affect the outcome of git-commit.

-

The default post-commit hook, when enabled, demonstrates how to -send out a commit notification e-mail.

update

@@ -381,6 +379,8 @@ based on filesystem group.

The standard output of this hook is sent to stderr, so if you want to report something to the git-send-pack on the other end, you can simply echo your messages.

+

The default update hook, when enabled, demonstrates how to +send out a notification e-mail.

post-update

@@ -406,7 +406,7 @@ you can redirect your output to your stderr.

diff --git a/hooks.txt b/hooks.txt index e3b76f96e..b083290d1 100644 --- a/hooks.txt +++ b/hooks.txt @@ -90,9 +90,6 @@ parameter, and is invoked after a commit is made. This hook is meant primarily for notification, and cannot affect the outcome of `git-commit`. -The default 'post-commit' hook, when enabled, demonstrates how to -send out a commit notification e-mail. - update ------ @@ -130,6 +127,8 @@ The standard output of this hook is sent to `stderr`, so if you want to report something to the `git-send-pack` on the other end, you can simply `echo` your messages. +The default 'update' hook, when enabled, demonstrates how to +send out a notification e-mail. post-update ----------- diff --git a/tutorial-2.html b/tutorial-2.html index 49a75b541..804c39501 100644 --- a/tutorial-2.html +++ b/tutorial-2.html @@ -600,23 +600,22 @@ situation:

$ git status
-#
-# Added but not yet committed:
-#   (will commit)
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file: closing.txt
 #
-#
-# Changed but not added:
-#   (use "git add file1 file2" to include for commit)
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
 #
 #       modified: file.txt
 #

Since the current state of closing.txt is cached in the index file, -it is listed as "added but not yet committed". Since file.txt has +it is listed as "Changes to be committed". Since file.txt has changes in the working directory that aren't reflected in the index, -it is marked "changed but not added". At this point, running "git +it is marked "changed but not updated". At this point, running "git commit" would create a commit that added closing.txt (with its new contents), but that didn't modify file.txt.

Also, note that a bare "git diff" shows the changes to file.txt, but @@ -646,7 +645,7 @@ example, creating a new commit.

diff --git a/tutorial-2.txt b/tutorial-2.txt index f363d17f0..8d8999271 100644 --- a/tutorial-2.txt +++ b/tutorial-2.txt @@ -352,24 +352,23 @@ situation: ------------------------------------------------ $ git status -# -# Added but not yet committed: -# (will commit) +# On branch master +# Changes to be committed: +# (use "git reset HEAD ..." to unstage) # # new file: closing.txt # -# -# Changed but not added: -# (use "git add file1 file2" to include for commit) +# Changed but not updated: +# (use "git add ..." to update what will be committed) # # modified: file.txt # ------------------------------------------------ Since the current state of closing.txt is cached in the index file, -it is listed as "added but not yet committed". Since file.txt has +it is listed as "Changes to be committed". Since file.txt has changes in the working directory that aren't reflected in the index, -it is marked "changed but not added". At this point, running "git +it is marked "changed but not updated". At this point, running "git commit" would create a commit that added closing.txt (with its new contents), but that didn't modify file.txt. diff --git a/tutorial.html b/tutorial.html index ac99896da..34b45f62a 100644 --- a/tutorial.html +++ b/tutorial.html @@ -346,33 +346,24 @@ commit in the body.

With git you have to explicitly "add" all the changed _content_ you want to commit together. This can be done in a few different ways:

1) By using git add <file_spec>…

-
-
-
This can be performed multiple times before a commit.  Note that this
+
This can be performed multiple times before a commit.  Note that this
 is not only for adding new files.  Even modified files must be
 added to the set of changes about to be committed.  The "git status"
 command gives you a summary of what is included so far for the
-next commit.  When done you should use the 'git commit' command to
-make it real.
-
-
-
-
Note: don't forget to 'add' a file again if you modified it after the
-first 'add' and before 'commit'. Otherwise only the previous added
+next commit.  When done you should use the git commit command to
+make it real.

+
Note: don't forget to add a file again if you modified it after the
+first add and before commit. Otherwise only the previous added
 state of that file will be committed. This is because git tracks
-content, so what you're really 'add'ing to the commit is the *content*
-of the file in the state it is in when you 'add' it.
-
+content, so what you're really add'ing to the commit is the content +of the file in the state it is in when you 'add it.

2) By using git commit -a directly

-
-
-
This is a quick way to automatically 'add' the content from all files
+
This is a quick way to automatically add the content from all files
 that were modified since the previous commit, and perform the actual
-commit without having to separately 'add' them beforehand.  This will
+commit without having to separately add them beforehand.  This will
 not add content from new files i.e. files that were never added before.
 Those files still have to be added explicitly before performing a
-commit.
-
+commit.

But here's a twist. If you do git commit <file1> <file2> … then only the changes belonging to those explicitly specified files will be committed, entirely bypassing the current "added" changes. Those "added" @@ -788,7 +779,7 @@ digressions that may be interesting at this point are:

diff --git a/tutorial.txt b/tutorial.txt index adb1e3275..ea3418909 100644 --- a/tutorial.txt +++ b/tutorial.txt @@ -101,27 +101,27 @@ want to commit together. This can be done in a few different ways: 1) By using 'git add ...' - This can be performed multiple times before a commit. Note that this - is not only for adding new files. Even modified files must be - added to the set of changes about to be committed. The "git status" - command gives you a summary of what is included so far for the - next commit. When done you should use the 'git commit' command to - make it real. - - Note: don't forget to 'add' a file again if you modified it after the - first 'add' and before 'commit'. Otherwise only the previous added - state of that file will be committed. This is because git tracks - content, so what you're really 'add'ing to the commit is the *content* - of the file in the state it is in when you 'add' it. +This can be performed multiple times before a commit. Note that this +is not only for adding new files. Even modified files must be +added to the set of changes about to be committed. The "git status" +command gives you a summary of what is included so far for the +next commit. When done you should use the 'git commit' command to +make it real. + +Note: don't forget to 'add' a file again if you modified it after the +first 'add' and before 'commit'. Otherwise only the previous added +state of that file will be committed. This is because git tracks +content, so what you're really 'add'ing to the commit is the *content* +of the file in the state it is in when you 'add' it. 2) By using 'git commit -a' directly - This is a quick way to automatically 'add' the content from all files - that were modified since the previous commit, and perform the actual - commit without having to separately 'add' them beforehand. This will - not add content from new files i.e. files that were never added before. - Those files still have to be added explicitly before performing a - commit. +This is a quick way to automatically 'add' the content from all files +that were modified since the previous commit, and perform the actual +commit without having to separately 'add' them beforehand. This will +not add content from new files i.e. files that were never added before. +Those files still have to be added explicitly before performing a +commit. But here's a twist. If you do 'git commit ...' then only the changes belonging to those explicitly specified files will be