From: Junio C Hamano <junio@hera.kernel.org>
Date: Mon, 12 Feb 2007 07:15:35 +0000 (+0000)
Subject: Autogenerated HTML docs for v1.5.0-rc4-345-gb4d2
X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=9dd8bb07118fe70186522d7d8fd7da7a785a2a5e;p=git.git

Autogenerated HTML docs for v1.5.0-rc4-345-gb4d2
---

diff --git a/git-am.html b/git-am.html
index ba3865bcf..993d2b4b8 100644
--- a/git-am.html
+++ b/git-am.html
@@ -274,7 +274,8 @@ git-am(1) Manual Page
 <div class="sectionbody">
 <div class="verseblock">
 <div class="content"><em>git-am</em> [--signoff] [--dotest=&lt;dir&gt;] [--utf8 | --no-utf8] [--binary] [--3way]
-         [--interactive] [--whitespace=&lt;option&gt;] &lt;mbox&gt;&#8230;
+         [--interactive] [--whitespace=&lt;option&gt;] [-C&lt;n&gt;] [-p&lt;n&gt;]
+         &lt;mbox&gt;&#8230;
 <em>git-am</em> [--skip | --resolved]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
@@ -383,11 +384,11 @@ default.   You could use <tt>--no-utf8</tt> to override this.</p>
 </p>
 </dd>
 <dt>
--C&lt;n&gt;
+-C&lt;n&gt;, -p&lt;n&gt;
 </dt>
 <dd>
 <p>
-        This flag is passed to the <tt>git-apply</tt> program that applies
+        These flag are passed to the <tt>git-apply</tt> program that applies
         the patch.
 </p>
 </dd>
@@ -458,7 +459,7 @@ names.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 12-Feb-2007 04:14:05 UTC
+Last updated 12-Feb-2007 07:15:19 UTC
 </div>
 </div>
 </body>
diff --git a/git-am.txt b/git-am.txt
index 77ef103b2..4fb1d8441 100644
--- a/git-am.txt
+++ b/git-am.txt
@@ -10,7 +10,8 @@ SYNOPSIS
 --------
 [verse]
 'git-am' [--signoff] [--dotest=<dir>] [--utf8 | --no-utf8] [--binary] [--3way]
-         [--interactive] [--whitespace=<option>] <mbox>...
+         [--interactive] [--whitespace=<option>] [-C<n>] [-p<n>]
+	 <mbox>...
 'git-am' [--skip | --resolved]
 
 DESCRIPTION
@@ -68,8 +69,8 @@ default.   You could use `--no-utf8` to override this.
 	This flag is passed to the `git-apply` program that applies
 	the patch.
 
--C<n>::
-	This flag is passed to the `git-apply` program that applies
+-C<n>, -p<n>::
+	These flag are passed to the `git-apply` program that applies
 	the patch.
 
 --interactive::
diff --git a/git-fast-import.html b/git-fast-import.html
index 61b066825..4a20ade1e 100644
--- a/git-fast-import.html
+++ b/git-fast-import.html
@@ -357,6 +357,20 @@ the frontend program in use.</p>
 </p>
 </dd>
 <dt>
+--export-pack-edges=&lt;file&gt;
+</dt>
+<dd>
+<p>
+        After creating a packfile, print a line of data to
+        &lt;file&gt; listing the filename of the packfile and the last
+        commit on each branch that was written to that packfile.
+        This information may be useful after importing projects
+        whose total object set exceeds the 4 GiB packfile limit,
+        as these commits can be used as edge points during calls
+        to <a href="git-pack-objects.html">git-pack-objects(1)</a>.
+</p>
+</dd>
+<dt>
 --quiet
 </dt>
 <dd>
@@ -1023,6 +1037,11 @@ code considerably.</p>
 <p>The branch LRU builtin to fast-import tends to behave very well, and the
 cost of activating an inactive branch is so low that bouncing around
 between branches has virtually no impact on import performance.</p>
+<h3>Handling Renames</h3>
+<p>When importing a renamed file or directory, simply delete the old
+name(s) and modify the new name(s) during the corresponding commit.
+Git performs rename detection after-the-fact, rather than explicitly
+during a commit.</p>
 <h3>Use Tag Fixup Branches</h3>
 <p>Some other SCM systems let the user create a tag from multiple
 files which are not from the same commit/changeset.  Or to create
@@ -1170,7 +1189,7 @@ memory footprint (less than 2.7 MiB per active branch).</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 09-Feb-2007 08:38:34 UTC
+Last updated 12-Feb-2007 07:15:19 UTC
 </div>
 </div>
 </body>
diff --git a/git-fast-import.txt b/git-fast-import.txt
index 2a5052072..939ec4652 100644
--- a/git-fast-import.txt
+++ b/git-fast-import.txt
@@ -64,6 +64,15 @@ OPTIONS
 	Frontends can use this file to validate imports after they
 	have been completed.
 
+--export-pack-edges=<file>::
+	After creating a packfile, print a line of data to
+	<file> listing the filename of the packfile and the last
+	commit on each branch that was written to that packfile.
+	This information may be useful after importing projects
+	whose total object set exceeds the 4 GiB packfile limit,
+	as these commits can be used as edge points during calls
+	to gitlink:git-pack-objects[1].
+
 --quiet::
 	Disable all non-fatal output, making fast-import silent when it
 	is successful.	This option disables the output shown by
@@ -706,6 +715,13 @@ The branch LRU builtin to fast-import tends to behave very well, and the
 cost of activating an inactive branch is so low that bouncing around
 between branches has virtually no impact on import performance.
 
+Handling Renames
+~~~~~~~~~~~~~~~~
+When importing a renamed file or directory, simply delete the old
+name(s) and modify the new name(s) during the corresponding commit.
+Git performs rename detection after-the-fact, rather than explicitly
+during a commit.
+
 Use Tag Fixup Branches
 ~~~~~~~~~~~~~~~~~~~~~~
 Some other SCM systems let the user create a tag from multiple
diff --git a/git-rebase.html b/git-rebase.html
index fcb907ac1..e7f45f9da 100644
--- a/git-rebase.html
+++ b/git-rebase.html
@@ -272,7 +272,7 @@ git-rebase(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-rebase</em> [-v] [--merge] [-CNUM] [--onto &lt;newbase&gt;] &lt;upstream&gt; [&lt;branch&gt;]</p>
+<p><em>git-rebase</em> [-v] [--merge] [-C&lt;n&gt;] [--onto &lt;newbase&gt;] &lt;upstream&gt; [&lt;branch&gt;]</p>
 <p><em>git-rebase</em> --continue | --skip | --abort</p>
 </div>
 <h2>DESCRIPTION</h2>
@@ -591,7 +591,7 @@ a rebase.  Upon completion, &lt;branch&gt; will be the current branch.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 09-Feb-2007 08:38:36 UTC
+Last updated 12-Feb-2007 07:15:21 UTC
 </div>
 </div>
 </body>
diff --git a/git-rebase.txt b/git-rebase.txt
index 3dff2dfae..f2ef1f7dc 100644
--- a/git-rebase.txt
+++ b/git-rebase.txt
@@ -7,7 +7,7 @@ git-rebase - Forward-port local commits to the updated upstream head
 
 SYNOPSIS
 --------
-'git-rebase' [-v] [--merge] [-CNUM] [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>]
 
 'git-rebase' --continue | --skip | --abort
 
diff --git a/git-tag.html b/git-tag.html
index d3609a826..03e8f5bac 100644
--- a/git-tag.html
+++ b/git-tag.html
@@ -386,6 +386,124 @@ it in the repository configuration as follows:</p>
 <pre><tt>signingkey = &lt;gpg-key-id&gt;</tt></pre>
 </div></div>
 </div>
+<h2>DISCUSSION</h2>
+<div class="sectionbody">
+<h3>On Re-tagging</h3>
+<p>What should you do when you tag a wrong commit and you would
+want to re-tag?</p>
+<p>If you never pushed anything out, just re-tag it. Use "-f" to
+replace the old one. And you're done.</p>
+<p>But if you have pushed things out (or others could just read
+your repository directly), then others will have already seen
+the old tag. In that case you can do one of two things:</p>
+<ol>
+<li>
+<p>
+The sane thing.
+Just admit you screwed up, and use a different name. Others have
+already seen one tag-name, and if you keep the same name, you
+may be in the situation that two people both have "version X",
+but they actually have <em>different</em> "X"'s.  So just call it "X.1"
+and be done with it.
+</p>
+</li>
+<li>
+<p>
+The insane thing.
+You really want to call the new version "X" too, <em>even though</em>
+others have already seen the old one. So just use "git tag -f"
+again, as if you hadn't already published the old one.
+</p>
+</li>
+</ol>
+<p>However, Git does <strong>not</strong> (and it should not)change tags behind
+users back. So if somebody already got the old tag, doing a "git
+pull" on your tree shouldn't just make them overwrite the old
+one.</p>
+<p>If somebody got a release tag from you, you cannot just change
+the tag for them by updating your own one. This is a big
+security issue, in that people MUST be able to trust their
+tag-names.  If you really want to do the insane thing, you need
+to just fess up to it, and tell people that you messed up. You
+can do that by making a very public announcement saying:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>Ok, I messed up, and I pushed out an earlier version tagged as X. I
+then fixed something, and retagged the *fixed* tree as X again.
+
+If you got the wrong tag, and want the new one, please delete
+the old one and fetch the new one by doing:
+
+        git tag -d X
+        git fetch origin tag X
+
+to get my updated tag.
+
+You can test which tag you have by doing
+
+        git rev-parse X
+
+which should return 0123456789abcdef.. if you have the new version.
+
+Sorry for inconvenience.</tt></pre>
+</div></div>
+<p>Does this seem a bit complicated?  It <strong>should</strong> be. There is no
+way that it would be correct to just "fix" it behind peoples
+backs. People need to know that their tags might have been
+changed.</p>
+<h3>On Automatic following</h3>
+<p>If you are following somebody else's tree, you are most likely
+using tracking branches (<tt>refs/heads/origin</tt> in traditional
+layout, or <tt>refs/remotes/origin/master</tt> in the separate-remote
+layout).  You usually want the tags from the other end.</p>
+<p>On the other hand, if you are fetching because you would want a
+one-shot merge from somebody else, you typically do not want to
+get tags from there.  This happens more often for people near
+the toplevel but not limited to them.  Mere mortals when pulling
+from each other do not necessarily want to automatically get
+private anchor point tags from the other person.</p>
+<p>You would notice "please pull" messages on the mailing list says
+repo URL and branch name alone.  This is designed to be easily
+cut&amp;pasted to "git fetch" command line:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>Linus, please pull from
+
+        git://git..../proj.git master
+
+to get the following updates...</tt></pre>
+</div></div>
+<p>becomes:</p>
+<div class="listingblock">
+<div class="content">
+<pre><tt>$ git pull git://git..../proj.git master</tt></pre>
+</div></div>
+<p>In such a case, you do not want to automatically follow other's
+tags.</p>
+<p>One important aspect of git is it is distributed, and being
+distributed largely means there is no inherent "upstream" or
+"downstream" in the system.  On the face of it, the above
+example might seem to indicate that the tag namespace is owned
+by upper echelon of people and tags only flow downwards, but
+that is not the case.  It only shows that the usage pattern
+determines who are interested in whose tags.</p>
+<p>A one-shot pull is a sign that a commit history is now crossing
+the boundary between one circle of people (e.g. "people who are
+primarily interested in networking part of the kernel") who may
+have their own set of tags (e.g. "this is the third release
+candidate from the networking group to be proposed for general
+consumption with 2.6.21 release") to another circle of people
+(e.g. "people who integrate various subsystem improvements").
+The latter are usually not interested in the detailed tags used
+internally in the former group (that is what "internal" means).
+That is why it is desirable not to follow tags automatically in
+this case.</p>
+<p>It may well be that among networking people, they may want to
+exchange the tags internal to their group, but in that workflow
+they are most likely tracking with each other's progress by
+having tracking branches.  Again, the heuristic to automatically
+follow such tags is a good thing.</p>
+</div>
 <h2>Author</h2>
 <div class="sectionbody">
 <p>Written by Linus Torvalds &lt;torvalds@osdl.org&gt;,
@@ -401,7 +519,7 @@ Junio C Hamano &lt;junkio@cox.net&gt; and Chris Wright &lt;chrisw@osdl.org&gt;.<
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 28-Jan-2007 10:29:11 UTC
+Last updated 12-Feb-2007 07:15:21 UTC
 </div>
 </div>
 </body>
diff --git a/git-tag.txt b/git-tag.txt
index 3f01e0bfc..70235e8dd 100644
--- a/git-tag.txt
+++ b/git-tag.txt
@@ -80,6 +80,137 @@ it in the repository configuration as follows:
 [user]
     signingkey = <gpg-key-id>
 
+
+DISCUSSION
+----------
+
+On Re-tagging
+~~~~~~~~~~~~~
+
+What should you do when you tag a wrong commit and you would
+want to re-tag?
+
+If you never pushed anything out, just re-tag it. Use "-f" to
+replace the old one. And you're done.
+
+But if you have pushed things out (or others could just read
+your repository directly), then others will have already seen
+the old tag. In that case you can do one of two things:
+
+. The sane thing.
+Just admit you screwed up, and use a different name. Others have
+already seen one tag-name, and if you keep the same name, you
+may be in the situation that two people both have "version X",
+but they actually have 'different' "X"'s.  So just call it "X.1"
+and be done with it.
+
+. The insane thing.
+You really want to call the new version "X" too, 'even though'
+others have already seen the old one. So just use "git tag -f"
+again, as if you hadn't already published the old one.
+
+However, Git does *not* (and it should not)change tags behind
+users back. So if somebody already got the old tag, doing a "git
+pull" on your tree shouldn't just make them overwrite the old
+one.
+
+If somebody got a release tag from you, you cannot just change
+the tag for them by updating your own one. This is a big
+security issue, in that people MUST be able to trust their
+tag-names.  If you really want to do the insane thing, you need
+to just fess up to it, and tell people that you messed up. You
+can do that by making a very public announcement saying:
+
+------------
+Ok, I messed up, and I pushed out an earlier version tagged as X. I
+then fixed something, and retagged the *fixed* tree as X again.
+
+If you got the wrong tag, and want the new one, please delete
+the old one and fetch the new one by doing:
+
+	git tag -d X
+	git fetch origin tag X
+
+to get my updated tag.
+
+You can test which tag you have by doing
+
+	git rev-parse X
+
+which should return 0123456789abcdef.. if you have the new version.
+
+Sorry for inconvenience.
+------------
+
+Does this seem a bit complicated?  It *should* be. There is no
+way that it would be correct to just "fix" it behind peoples
+backs. People need to know that their tags might have been
+changed.
+
+
+On Automatic following
+~~~~~~~~~~~~~~~~~~~~~~
+
+If you are following somebody else's tree, you are most likely
+using tracking branches (`refs/heads/origin` in traditional
+layout, or `refs/remotes/origin/master` in the separate-remote
+layout).  You usually want the tags from the other end.
+
+On the other hand, if you are fetching because you would want a
+one-shot merge from somebody else, you typically do not want to
+get tags from there.  This happens more often for people near
+the toplevel but not limited to them.  Mere mortals when pulling
+from each other do not necessarily want to automatically get
+private anchor point tags from the other person.
+
+You would notice "please pull" messages on the mailing list says
+repo URL and branch name alone.  This is designed to be easily
+cut&pasted to "git fetch" command line:
+
+------------
+Linus, please pull from
+
+	git://git..../proj.git master
+
+to get the following updates...
+------------
+
+becomes:
+
+------------
+$ git pull git://git..../proj.git master
+------------
+
+In such a case, you do not want to automatically follow other's
+tags.
+
+One important aspect of git is it is distributed, and being
+distributed largely means there is no inherent "upstream" or
+"downstream" in the system.  On the face of it, the above
+example might seem to indicate that the tag namespace is owned
+by upper echelon of people and tags only flow downwards, but
+that is not the case.  It only shows that the usage pattern
+determines who are interested in whose tags.
+
+A one-shot pull is a sign that a commit history is now crossing
+the boundary between one circle of people (e.g. "people who are
+primarily interested in networking part of the kernel") who may
+have their own set of tags (e.g. "this is the third release
+candidate from the networking group to be proposed for general
+consumption with 2.6.21 release") to another circle of people
+(e.g. "people who integrate various subsystem improvements").
+The latter are usually not interested in the detailed tags used
+internally in the former group (that is what "internal" means).
+That is why it is desirable not to follow tags automatically in
+this case.
+
+It may well be that among networking people, they may want to
+exchange the tags internal to their group, but in that workflow
+they are most likely tracking with each other's progress by
+having tracking branches.  Again, the heuristic to automatically
+follow such tags is a good thing.
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>,
diff --git a/git.html b/git.html
index 5a73f3dbb..ea92c2857 100644
--- a/git.html
+++ b/git.html
@@ -2296,7 +2296,7 @@ contributors on the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 12-Feb-2007 04:14:07 UTC
+Last updated 12-Feb-2007 07:15:22 UTC
 </div>
 </div>
 </body>