Autogenerated HTML docs for v1.7.11-3-g60475

1 files changed, 23 insertions, 22 deletions

diff --git a/gitworkflows.html b/gitworkflows.html
index 6670703e2..16b54116d 100644
--- a/gitworkflows.html
+++ b/gitworkflows.html
@@ -605,7 +605,7 @@ logical steps, and commit each of them.  They should be consistent,
 working independently of any later commits, pass the test suite, etc.

 This makes the review process much easier, and the history much more

 useful for later inspection and analysis, for example with

- and .</p></div>

+<a href="git-blame.html">git-blame(1)</a> and <a href="git-bisect.html">git-bisect(1)</a>.</p></div>

 <div class="paragraph"><p>To achieve this, try to split your work into small steps from the very

 beginning. It is always easier to squash a few commits together than

 to split one big commit into several.  Don&#8217;t be afraid of making too

@@ -613,13 +613,13 @@ small or imperfect steps along the way. You can always go back later
 and edit the commits with <tt>git rebase --interactive</tt> before you

 publish them.  You can use <tt>git stash save --keep-index</tt> to run the

 test suite independent of other uncommitted changes; see the EXAMPLES

-section of .</p></div>

+section of <a href="git-stash.html">git-stash(1)</a>.</p></div>

 </div>

 <h2 id="_managing_branches">MANAGING BRANCHES</h2>

 <div class="sectionbody">

 <div class="paragraph"><p>There are two main tools that can be used to include changes from one

-branch on another:  and

-.</p></div>

+branch on another: <a href="git-merge.html">git-merge(1)</a> and

+<a href="git-cherry-pick.html">git-cherry-pick(1)</a>.</p></div>

 <div class="paragraph"><p>Merges have many advantages, so we try to solve as many problems as

 possible with merges alone.  Cherry-picking is still occasionally

 useful; see "Merging upwards" below for an example.</p></div>

@@ -683,7 +683,7 @@ other.</p></div>
 </div></div>

 <div class="paragraph"><p>This gives a very controlled flow of fixes.  If you notice that you

 have applied a fix to e.g. <em>master</em> that is also required in <em>maint</em>,

-you will need to cherry-pick it (using )

+you will need to cherry-pick it (using <a href="git-cherry-pick.html">git-cherry-pick(1)</a>)

 downwards.  This will happen a few times and is nothing to worry about

 unless you do it very frequently.</p></div>

 <h3 id="_topic_branches">Topic branches</h3><div style="clear:left"></div>

@@ -726,13 +726,13 @@ If you find you need new features from the branch <em>other</em> to continue
 <li>

 <p>

 If you find you forked off the wrong branch and want to move it

-  "back in time", use .

+  "back in time", use <a href="git-rebase.html">git-rebase(1)</a>.

 </p>

 </li>

 </ul></div>

 <div class="paragraph"><p>Note that the last point clashes with the other two: a topic that has

 been merged elsewhere should not be rebased.  See the section on

-RECOVERING FROM UPSTREAM REBASE in .</p></div>

+RECOVERING FROM UPSTREAM REBASE in <a href="git-rebase.html">git-rebase(1)</a>.</p></div>

 <div class="paragraph"><p>We should point out that "habitually" (regularly for no real reason)

 merging an integration branch into your topics&#8201;&#8212;&#8201;and by extension,

 merging anything upstream into anything downstream on a regular basis&#8201;&#8212;&#8201;is frowned upon:</p></div>

@@ -907,19 +907,19 @@ history; downstream base their work on the official history.</p></div>
 <div class="ulist"><ul>

 <li>

 <p>

- copies your branches to a remote repository,

+<a href="git-push.html">git-push(1)</a> copies your branches to a remote repository,

   usually to one that can be read by all involved parties;

 </p>

 </li>

 <li>

 <p>

- that copies remote branches to your repository;

+<a href="git-fetch.html">git-fetch(1)</a> that copies remote branches to your repository;

   and

 </p>

 </li>

 <li>

 <p>

- that does fetch and merge in one go.

+<a href="git-pull.html">git-pull(1)</a> that does fetch and merge in one go.

 </p>

 </li>

 </ul></div>

@@ -933,7 +933,7 @@ to merge the remote branch.</p></div>
 from.</p></div>

 </div></div>

 <div class="paragraph"><p>You will still have to tell people by other means, such as mail.  (Git

-provides the  to send preformatted pull

+provides the <a href="git-request-pull.html">git-request-pull(1)</a> to send preformatted pull

 requests to upstream maintainers to simplify this task.)</p></div>

 <div class="paragraph"><p>If you just want to get the newest copies of the integration branches,

 staying up to date is easy too:</p></div>

@@ -967,7 +967,7 @@ downstream <em>should</em> merge from upstream.</p></div>
 <h3 id="_patch_workflow">Patch workflow</h3><div style="clear:left"></div>

 <div class="paragraph"><p>If you are a contributor that sends changes upstream in the form of

 emails, you should use topic branches as usual (see above).  Then use

- to generate the corresponding emails

+<a href="git-format-patch.html">git-format-patch(1)</a> to generate the corresponding emails

 (highly recommended over manually formatting them because it makes the

 maintainer&#8217;s life easier).</p></div>

 <div class="exampleblock">

@@ -987,7 +987,7 @@ maintainer&#8217;s life easier).</p></div>
 </li>

 </ul></div>

 </div></div>

-<div class="paragraph"><p>See the  and 

+<div class="paragraph"><p>See the <a href="git-format-patch.html">git-format-patch(1)</a> and <a href="git-send-email.html">git-send-email(1)</a>

 manpages for further usage notes.</p></div>

 <div class="paragraph"><p>If the maintainer tells you that your patch no longer applies to the

 current upstream, you will have to rebase your topic (you cannot use a

@@ -1010,22 +1010,23 @@ create a new topic branch and use <em>git am</em> to import the commits:</p></di
 </div></div>

 <div class="paragraph"><p>One feature worth pointing out is the three-way merge, which can help

 if you get conflicts: <tt>git am -3</tt> will use index information contained

-in patches to figure out the merge base.  See  for

+in patches to figure out the merge base.  See <a href="git-am.html">git-am(1)</a> for

 other options.</p></div>

 </div>

 <h2 id="_see_also">SEE ALSO</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>,

-,

-,

-,

-,

-,

-,</p></div>

+<div class="paragraph"><p><a href="gittutorial.html">gittutorial(7)</a>,

+<a href="git-push.html">git-push(1)</a>,

+<a href="git-pull.html">git-pull(1)</a>,

+<a href="git-merge.html">git-merge(1)</a>,

+<a href="git-rebase.html">git-rebase(1)</a>,

+<a href="git-format-patch.html">git-format-patch(1)</a>,

+<a href="git-send-email.html">git-send-email(1)</a>,

+<a href="git-am.html">git-am(1)</a></p></div>

 </div>

 <h2 id="_git">GIT</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>Part of the  suite.</p></div>

+<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite.</p></div>

 </div>

 </div>

 <div id="footnotes"><hr /></div>