<p>Although git is a truly distributed system, it is often\r
convenient to organize your project with an informal hierarchy\r
of developers. Linux kernel development is run this way. There\r
-is a nice illustration (page 17, "Merges to Mainline") in Randy\r
-Dunlap's presentation (<tt>http://tinyurl.com/a2jdg</tt>).</p>\r
+is a nice illustration (page 17, "Merges to Mainline") in\r
+<a href="http://tinyurl.com/a2jdg">Randy Dunlap's presentation</a>.</p>\r
<p>It should be stressed that this hierarchy is purely <strong>informal</strong>.\r
There is nothing fundamental in git that enforces the "chain of\r
patch flow" this hierarchy implies. You do not have to pull\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 02-Feb-2007 07:34:56 UTC\r
+Last updated 03-Feb-2007 08:07:25 UTC\r
</div>\r
</div>\r
</body>\r
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
parameter, and is invoked after a commit is made.</p>\r
<p>This hook is meant primarily for notification, and cannot affect\r
the outcome of <tt>git-commit</tt>.</p>\r
-<p>The default <em>post-commit</em> hook, when enabled, demonstrates how to\r
-send out a commit notification e-mail.</p>\r
</div>\r
<h2>update</h2>\r
<div class="sectionbody">\r
<p>The standard output of this hook is sent to <tt>stderr</tt>, so if you\r
want to report something to the <tt>git-send-pack</tt> on the other end,\r
you can simply <tt>echo</tt> your messages.</p>\r
+<p>The default <em>update</em> hook, when enabled, demonstrates how to\r
+send out a notification e-mail.</p>\r
</div>\r
<h2>post-update</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 13-Jan-2007 08:09:09 UTC\r
+Last updated 03-Feb-2007 08:07:27 UTC\r
</div>\r
</div>\r
</body>\r
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
------
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
-----------
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git status\r
-#\r
-# Added but not yet committed:\r
-# (will commit)\r
+# On branch master\r
+# Changes to be committed:\r
+# (use "git reset HEAD <file>..." to unstage)\r
#\r
# new file: closing.txt\r
#\r
-#\r
-# Changed but not added:\r
-# (use "git add file1 file2" to include for commit)\r
+# Changed but not updated:\r
+# (use "git add <file>..." to update what will be committed)\r
#\r
# modified: file.txt\r
#</tt></pre>\r
</div></div>\r
<p>Since the current state of closing.txt is cached in the index file,\r
-it is listed as "added but not yet committed". Since file.txt has\r
+it is listed as "Changes to be committed". Since file.txt has\r
changes in the working directory that aren't reflected in the index,\r
-it is marked "changed but not added". At this point, running "git\r
+it is marked "changed but not updated". At this point, running "git\r
commit" would create a commit that added closing.txt (with its new\r
contents), but that didn't modify file.txt.</p>\r
<p>Also, note that a bare "git diff" shows the changes to file.txt, but\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 22-Jan-2007 08:59:55 UTC\r
+Last updated 03-Feb-2007 08:07:24 UTC\r
</div>\r
</div>\r
</body>\r
------------------------------------------------
$ 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.
<p>With git you have to explicitly "add" all the changed _content_ you\r
want to commit together. This can be done in a few different ways:</p>\r
<p>1) By using <em>git add <file_spec>…</em></p>\r
-<div class="literalblock">\r
-<div class="content">\r
-<pre><tt>This can be performed multiple times before a commit. Note that this\r
+<p>This can be performed multiple times before a commit. Note that this\r
is not only for adding new files. Even modified files must be\r
added to the set of changes about to be committed. The "git status"\r
command gives you a summary of what is included so far for the\r
-next commit. When done you should use the 'git commit' command to\r
-make it real.</tt></pre>\r
-</div></div>\r
-<div class="literalblock">\r
-<div class="content">\r
-<pre><tt>Note: don't forget to 'add' a file again if you modified it after the\r
-first 'add' and before 'commit'. Otherwise only the previous added\r
+next commit. When done you should use the <em>git commit</em> command to\r
+make it real.</p>\r
+<p>Note: don't forget to <em>add</em> a file again if you modified it after the\r
+first <em>add</em> and before <em>commit</em>. Otherwise only the previous added\r
state of that file will be committed. This is because git tracks\r
-content, so what you're really 'add'ing to the commit is the *content*\r
-of the file in the state it is in when you 'add' it.</tt></pre>\r
-</div></div>\r
+content, so what you're really <em>add'ing to the commit is the <strong>content</strong>\r
+of the file in the state it is in when you 'add</em> it.</p>\r
<p>2) By using <em>git commit -a</em> directly</p>\r
-<div class="literalblock">\r
-<div class="content">\r
-<pre><tt>This is a quick way to automatically 'add' the content from all files\r
+<p>This is a quick way to automatically <em>add</em> the content from all files\r
that were modified since the previous commit, and perform the actual\r
-commit without having to separately 'add' them beforehand. This will\r
+commit without having to separately <em>add</em> them beforehand. This will\r
not add content from new files i.e. files that were never added before.\r
Those files still have to be added explicitly before performing a\r
-commit.</tt></pre>\r
-</div></div>\r
+commit.</p>\r
<p>But here's a twist. If you do <em>git commit <file1> <file2> …</em> then only\r
the changes belonging to those explicitly specified files will be\r
committed, entirely bypassing the current "added" changes. Those "added"\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 29-Jan-2007 02:55:15 UTC\r
+Last updated 03-Feb-2007 08:07:23 UTC\r
</div>\r
</div>\r
</body>\r
1) By using 'git add <file_spec>...'
- 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 <file1> <file2> ...' then only
the changes belonging to those explicitly specified files will be
projects / git.git / commitdiff