Autogenerated HTML docs for v1.5.6.1-156-ge903b

1 files changed, 78 insertions, 79 deletions

diff --git a/git-svn.html b/git-svn.html
index 545240f7a..6c56d7df1 100644
--- a/git-svn.html
+++ b/git-svn.html
@@ -272,19 +272,19 @@ git-svn(1) Manual Page
 </div>

 <h2>SYNOPSIS</h2>

 <div class="sectionbody">

-<p><em>git-svn</em> &lt;command&gt; [options] [arguments]</p>

+<p><em>git svn</em> &lt;command&gt; [options] [arguments]</p>

 </div>

 <h2>DESCRIPTION</h2>

 <div class="sectionbody">

-<p>git-svn is a simple conduit for changesets between Subversion and git.

+<p><tt>git-svn</tt> is a simple conduit for changesets between Subversion and git.

 It is not to be confused with <a href="git-svnimport.html">git-svnimport(1)</a>, which is

 read-only.</p>

-<p>git-svn was originally designed for an individual developer who wants a

+<p><tt>git-svn</tt> was originally designed for an individual developer who wants a

 bidirectional flow of changesets between a single branch in Subversion

 and an arbitrary number of branches in git.  Since its inception,

-git-svn has gained the ability to track multiple branches in a manner

-similar to git-svnimport.</p>

-<p>git-svn is especially useful when it comes to tracking repositories

+<tt>git-svn</tt> has gained the ability to track multiple branches in a manner

+similar to <tt>git-svnimport</tt>.</p>

+<p><tt>git-svn</tt> is especially useful when it comes to tracking repositories

 not organized in the way Subversion developers recommend (trunk,

 branches, tags directories).</p>

 </div>

@@ -297,7 +297,7 @@ branches, tags directories).</p>
 <dd>

 <p>

         Initializes an empty git repository with additional

-        metadata directories for git-svn.  The Subversion URL

+        metadata directories for <tt>git-svn</tt>.  The Subversion URL

         may be specified as a command-line argument, or as full

         URL arguments to -T/-t/-b.  Optionally, the target

         directory to operate on can be specified as a second

@@ -457,13 +457,13 @@ branches, tags directories).</p>
         This fetches revisions from the SVN parent of the current HEAD

         and rebases the current (uncommitted to SVN) work against it.

 </p>

-<p>This works similarly to <em>svn update</em> or <em>git-pull</em> except that

-it preserves linear history with <em>git-rebase</em> instead of

-<em>git-merge</em> for ease of dcommiting with git-svn.</p>

-<p>This accepts all options that <em>git-svn fetch</em> and <em>git-rebase</em>

-accepts.  However <em>--fetch-all</em> only fetches from the current

+<p>This works similarly to <tt>svn update</tt> or <tt>git-pull</tt> except that

+it preserves linear history with <tt>git-rebase</tt> instead of

+<tt>git-merge</tt> for ease of dcommiting with <tt>git-svn</tt>.</p>

+<p>This accepts all options that <tt>git-svn fetch</tt> and <tt>git-rebase</tt>

+accept.  However, <em>--fetch-all</em> only fetches from the current

 [svn-remote], and not all [svn-remote] definitions.</p>

-<p>Like <em>git-rebase</em>; this requires that the working tree be clean

+<p>Like <tt>git-rebase</tt>; this requires that the working tree be clean

 and have no uncommitted changes.</p>

 <dl>

 <dt>

@@ -474,7 +474,7 @@ and have no uncommitted changes.</p>
 </dt>

 <dd>

 <p>

-        Do not fetch remotely; only run <em>git-rebase</em> against the

+        Do not fetch remotely; only run <tt>git-rebase</tt> against the

         last fetched commit from the upstream SVN.

 </p>

 </dd>

@@ -489,7 +489,7 @@ and have no uncommitted changes.</p>
         repository, and then rebase or reset (depending on whether or

         not there is a diff between SVN and head).  This will create

         a revision in SVN for each commit in git.

-        It is recommended that you run git-svn fetch and rebase (not

+        It is recommended that you run <tt>git-svn</tt> fetch and rebase (not

         pull or merge) your commits against the latest changes in the

         SVN repository.

         An optional command-line argument may be specified as an

@@ -585,7 +585,7 @@ client converts the UTC time to the local time (or based on the TZ=
 environment). This command has the same behaviour.</td>

 </tr></table>

 </div>

-<p>Any other arguments are passed directly to `git log'</p>

+<p>Any other arguments are passed directly to <tt>git-log</tt></p>

 </dd>

 <dt>

 <em>blame</em>

@@ -594,10 +594,10 @@ environment). This command has the same behaviour.</td>
 <p>

        Show what revision and author last modified each line of a file. The

        output of this mode is format-compatible with the output of

-       `svn blame' by default. Like the SVN blame command,

+       <tt>svn blame' by default. Like the SVN blame command,

        local uncommitted changes in the working copy are ignored;

        the version of the file in the HEAD revision is annotated. Unknown

-       arguments are passed directly to git-blame.

+       arguments are passed directly to `git-blame</tt>.

 </p>

 <dl>

 <dt>

@@ -605,7 +605,7 @@ environment). This command has the same behaviour.</td>
 </dt>

 <dd>

 <p>

-        Produce output in the same format as `git blame', but with

+        Produce output in the same format as <tt>git-blame</tt>, but with

         SVN revision numbers instead of git commit hashes. In this mode,

         changes that haven't been committed to SVN (including local

         working-copy edits) are shown as revision 0.

@@ -637,7 +637,7 @@ environment). This command has the same behaviour.</td>
         absolutely no attempts to do patching when committing to SVN, it

         simply overwrites files with those specified in the tree or

         commit.  All merging is assumed to have taken place

-        independently of git-svn functions.

+        independently of <tt>git-svn</tt> functions.

 </p>

 </dd>

 <dt>

@@ -668,12 +668,12 @@ environment). This command has the same behaviour.</td>
 <p>

         Commits the diff of two tree-ish arguments from the

         command-line.  This command is intended for interoperability with

-        git-svnimport and does not rely on being inside an git-svn

-        init-ed repository.  This command takes three arguments, (a) the

+        <tt>git-svnimport</tt> and does not rely on being inside an <tt>git-svn

+        init</tt>-ed repository.  This command takes three arguments, (a) the

         original tree to diff against, (b) the new tree result, (c) the

         URL of the target Subversion repository.  The final argument

-        (URL) may be omitted if you are working from a git-svn-aware

-        repository (that has been init-ed with git-svn).

+        (URL) may be omitted if you are working from a <tt>git-svn</tt>-aware

+        repository (that has been <tt>init</tt>-ed with <tt>git-svn</tt>).

         The -r&lt;revision&gt; option is required for this.

 </p>

 </dd>

@@ -730,7 +730,7 @@ environment). This command has the same behaviour.</td>
 <dd>

 <p>

         Only used with the <em>init</em> command.

-        These are passed directly to <a href="git-init.html">git-init(1)</a>.

+        These are passed directly to <tt>git-init</tt>.

 </p>

 </dd>

 <dt>

@@ -762,7 +762,7 @@ Only used with the <em>set-tree</em> command.
 </p>

 <p>Read a list of commits from stdin and commit them in reverse

 order.  Only the leading sha1 is read from each line, so

-git-rev-list --pretty=oneline output can be used.</p>

+<tt>git-rev-list --pretty=oneline</tt> output can be used.</p>

 </dd>

 <dt>

 --rmdir

@@ -803,7 +803,7 @@ tree objects.</p>
 <p>

 Only used with the <em>dcommit</em>, <em>set-tree</em> and <em>commit-diff</em> commands.

 </p>

-<p>They are both passed directly to git-diff-tree see

+<p>They are both passed directly to <tt>git-diff-tree</tt>; see

 <a href="git-diff-tree.html">git-diff-tree(1)</a> for more information.</p>

 <div class="verseblock">

 <div class="content">config key: svn.l

@@ -817,17 +817,17 @@ config key: svn.findcopiesharder</div></div>
 </dt>

 <dd>

 <p>

-Syntax is compatible with the files used by git-svnimport and

-git-cvsimport:

+Syntax is compatible with the files used by <tt>git-svnimport</tt> and

+<tt>git-cvsimport</tt>:

 </p>

 <div class="listingblock">

 <div class="content">

 <pre><tt>        loginname = Joe User &lt;user@example.com&gt;</tt></pre>

 </div></div>

-<p>If this option is specified and git-svn encounters an SVN

-committer name that does not exist in the authors-file, git-svn

+<p>If this option is specified and <tt>git-svn</tt> encounters an SVN

+committer name that does not exist in the authors-file, <tt>git-svn</tt>

 will abort operation. The user will then have to add the

-appropriate entry.  Re-running the previous git-svn command

+appropriate entry.  Re-running the previous <tt>git-svn</tt> command

 after the authors-file is modified should continue operation.</p>

 <p>config key: svn.authorsfile</p>

 </dd>

@@ -839,7 +839,7 @@ after the authors-file is modified should continue operation.</p>
 </dt>

 <dd>

 <p>

-        Make git-svn less verbose.

+        Make <tt>git-svn</tt> less verbose.

 </p>

 </dd>

 <dt>

@@ -856,7 +856,7 @@ with many revisions.
 <p>--repack takes an optional argument for the number of revisions

 to fetch before repacking.  This defaults to repacking every

 1000 commits fetched if no argument is specified.</p>

-<p>--repack-flags are passed directly to <a href="git-repack.html">git-repack(1)</a>.</p>

+<p>--repack-flags are passed directly to <tt>git-repack</tt>.</p>

 <div class="verseblock">

 <div class="content">config key: svn.repack

 config key: svn.repackflags</div></div>

@@ -877,8 +877,8 @@ config key: svn.repackflags</div></div>
 <p>

 These are only used with the <em>dcommit</em> and <em>rebase</em> commands.

 </p>

-<p>Passed directly to git-rebase when using <em>dcommit</em> if a

-<em>git-reset</em> cannot be used (see dcommit).</p>

+<p>Passed directly to <tt>git-rebase</tt> when using <em>dcommit</em> if a

+<tt>git-reset</tt> cannot be used (see <em>dcommit</em>).</p>

 </dd>

 <dt>

 -n

@@ -954,12 +954,12 @@ svn-remote.&lt;name&gt;.noMetadata
 </dt>

 <dd>

 <p>

-This gets rid of the git-svn-id: lines at the end of every commit.

+This gets rid of the <em>git-svn-id:</em> lines at the end of every commit.

 </p>

-<p>If you lose your .git/svn/git-svn/.rev_db file, git-svn will not

+<p>If you lose your .git/svn/git-svn/.rev_db file, <tt>git-svn</tt> will not

 be able to rebuild it and you won't be able to fetch again,

 either.  This is fine for one-shot imports.</p>

-<p>The <em>git-svn log</em> command will not work on repositories using

+<p>The <tt>git-svn log</tt> command will not work on repositories using

 this, either.  Using this conflicts with the <em>useSvmProps</em>

 option for (hopefully) obvious reasons.</p>

 </dd>

@@ -971,7 +971,7 @@ svn-remote.&lt;name&gt;.useSvmProps
 </dt>

 <dd>

 <p>

-This allows git-svn to re-map repository URLs and UUIDs from

+This allows <tt>git-svn</tt> to re-map repository URLs and UUIDs from

 mirrors created using SVN::Mirror (or svk) for metadata.

 </p>

 <p>If an SVN revision has a property, "svm:headrev", it is likely

@@ -1001,7 +1001,7 @@ svn-remote.&lt;name&gt;.rewriteRoot
 <dd>

 <p>

         This allows users to create repositories from alternate

-        URLs.  For example, an administrator could run git-svn on the

+        URLs.  For example, an administrator could run <tt>git-svn</tt> on the

         server locally (accessing via file://) but wish to distribute

         the repository with a public http:// or svn:// URL in the

         metadata so users of it will see the public URL.

@@ -1009,7 +1009,7 @@ svn-remote.&lt;name&gt;.rewriteRoot
 </dd>

 </dl>

 <p>Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps

-options all affect the metadata generated and used by git-svn; they

+options all affect the metadata generated and used by <tt>git-svn</tt>; they

 <strong>must</strong> be set in the configuration file before any history is imported

 and these settings should never be changed once they are set.</p>

 <p>Additionally, only one of these four options can be used per-svn-remote

@@ -1021,7 +1021,7 @@ section because they affect the <em>git-svn-id:</em> metadata line.</p>
 <div class="listingblock">

 <div class="content">

 <pre><tt># Clone a repo (like git clone):

-        git-svn clone http://svn.foo.org/project/trunk

+        git svn clone http://svn.foo.org/project/trunk

 # Enter the newly cloned directory:

         cd trunk

 # You should be on master branch, double-check with git-branch

@@ -1030,19 +1030,19 @@ section because they affect the <em>git-svn-id:</em> metadata line.</p>
         git commit ...

 # Something is committed to SVN, rebase your local changes against the

 # latest changes in SVN:

-        git-svn rebase

+        git svn rebase

 # Now commit your changes (that were committed previously using git) to SVN,

 # as well as automatically updating your working HEAD:

-        git-svn dcommit

+        git svn dcommit

 # Append svn:ignore settings to the default git exclude file:

-        git-svn show-ignore &gt;&gt; .git/info/exclude</tt></pre>

+        git svn show-ignore &gt;&gt; .git/info/exclude</tt></pre>

 </div></div>

 <p>Tracking and contributing to an entire Subversion-managed project

 (complete with a trunk, tags and branches):</p>

 <div class="listingblock">

 <div class="content">

 <pre><tt># Clone a repo (like git clone):

-        git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags

+        git svn clone http://svn.foo.org/project -T trunk -b branches -t tags

 # View all branches and tags you have cloned:

         git branch -r

 # Reset your master to trunk (or any other branch, replacing 'trunk'

@@ -1051,46 +1051,46 @@ section because they affect the <em>git-svn-id:</em> metadata line.</p>
 # You may only dcommit to one branch/tag/trunk at a time.  The usage

 # of dcommit/rebase/show-ignore should be the same as above.</tt></pre>

 </div></div>

-<p>The initial <em>git-svn clone</em> can be quite time-consuming

+<p>The initial <tt>git-svn clone</tt> can be quite time-consuming

 (especially for large Subversion repositories). If multiple

 people (or one person with multiple machines) want to use

-git-svn to interact with the same Subversion repository, you can

-do the initial <em>git-svn clone</em> to a repository on a server and

-have each person clone that repository with <em>git clone</em>:</p>

+<tt>git-svn</tt> to interact with the same Subversion repository, you can

+do the initial <tt>git-svn clone</tt> to a repository on a server and

+have each person clone that repository with <tt>git-clone</tt>:</p>

 <div class="listingblock">

 <div class="content">

 <pre><tt># Do the initial import on a server

-        ssh server "cd /pub &amp;&amp; git-svn clone http://svn.foo.org/project

+        ssh server "cd /pub &amp;&amp; git svn clone http://svn.foo.org/project

 # Clone locally - make sure the refs/remotes/ space matches the server

         mkdir project

         cd project

-        git-init

+        git init

         git remote add origin server:/pub/project

         git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'

         git fetch

 # Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)

-        git-svn init http://svn.foo.org/project

+        git svn init http://svn.foo.org/project

 # Pull the latest changes from Subversion

-        git-svn rebase</tt></pre>

+        git svn rebase</tt></pre>

 </div></div>

 </div>

 <h2>REBASE VS. PULL/MERGE</h2>

 <div class="sectionbody">

-<p>Originally, git-svn recommended that the remotes/git-svn branch be

+<p>Originally, <tt>git-svn</tt> recommended that the <em>remotes/git-svn</em> branch be

 pulled or merged from.  This is because the author favored

-<em>git-svn set-tree B</em> to commit a single head rather than the

-<em>git-svn set-tree A..B</em> notation to commit multiple commits.</p>

-<p>If you use <em>git-svn set-tree A..B</em> to commit several diffs and you do

+<tt>git svn set-tree B</tt> to commit a single head rather than the

+<tt>git svn set-tree A..B</tt> notation to commit multiple commits.</p>

+<p>If you use <tt>git svn set-tree A..B</tt> to commit several diffs and you do

 not have the latest remotes/git-svn merged into my-branch, you should

-use <em>git-svn rebase</em> to update your work branch instead of <em>git pull</em> or

-<em>git merge</em>.  <em>pull/merge</em> can cause non-linear history to be flattened

+use <tt>git svn rebase</tt> to update your work branch instead of <tt>git pull</tt> or

+<tt>git merge</tt>.  <tt>pull</tt>/`merge' can cause non-linear history to be flattened

 when committing into SVN, which can lead to merge commits reversing

 previous commits in SVN.</p>

 </div>

 <h2>DESIGN PHILOSOPHY</h2>

 <div class="sectionbody">

 <p>Merge tracking in Subversion is lacking and doing branched development

-with Subversion can be cumbersome as a result.  While git-svn can track

+with Subversion can be cumbersome as a result.  While <tt>git-svn</tt> can track

 copy history (including branches and tags) for repositories adopting a

 standard layout, it cannot yet represent merge history that happened

 inside git back upstream to SVN users.  Therefore it is advised that

@@ -1100,26 +1100,26 @@ compatibility with SVN (see the CAVEATS section below).</p>
 <h2>CAVEATS</h2>

 <div class="sectionbody">

 <p>For the sake of simplicity and interoperating with a less-capable system

-(SVN), it is recommended that all git-svn users clone, fetch and dcommit

-directly from the SVN server, and avoid all git-clone/pull/merge/push

+(SVN), it is recommended that all <tt>git-svn</tt> users clone, fetch and dcommit

+directly from the SVN server, and avoid all <tt>git-clone</tt>/<tt>pull</tt>/<tt>merge</tt>/<tt>push</tt>

 operations between git repositories and branches.  The recommended

 method of exchanging code between git branches and users is

-git-format-patch and git-am, or just dcommiting to the SVN repository.</p>

-<p>Running <em>git-merge</em> or <em>git-pull</em> is NOT recommended on a branch you

-plan to dcommit from.  Subversion does not represent merges in any

+<tt>git-format-patch</tt> and <tt>git-am</tt>, or just 'dcommit'ing to the SVN repository.</p>

+<p>Running <tt>git-merge</tt> or <tt>git-pull</tt> is NOT recommended on a branch you

+plan to <em>dcommit</em> from.  Subversion does not represent merges in any

 reasonable or useful fashion; so users using Subversion cannot see any

 merges you've made.  Furthermore, if you merge or pull from a git branch

-that is a mirror of an SVN branch, dcommit may commit to the wrong

+that is a mirror of an SVN branch, <em>dcommit</em> may commit to the wrong

 branch.</p>

-<p><em>git-clone</em> does not clone branches under the refs/remotes/ hierarchy or

-any git-svn metadata, or config.  So repositories created and managed with

-using git-svn should use rsync(1) for cloning, if cloning is to be done

+<p><tt>git-clone</tt> does not clone branches under the refs/remotes/ hierarchy or

+any <tt>git-svn</tt> metadata, or config.  So repositories created and managed with

+using <tt>git-svn</tt> should use <tt>rsync</tt> for cloning, if cloning is to be done

 at all.</p>

-<p>Since <em>dcommit</em> uses rebase internally, any git branches you git-push to

-before dcommit on will require forcing an overwrite of the existing ref

+<p>Since <em>dcommit</em> uses rebase internally, any git branches you <tt>git-push</tt> to

+before <em>dcommit</em> on will require forcing an overwrite of the existing ref

 on the remote repository.  This is generally considered bad practice,

-see the git-push(1) documentation for details.</p>

-<p>Do not use the --amend option of git-commit(1) on a change you've

+see the <a href="git-push.html">git-push(1)</a> documentation for details.</p>

+<p>Do not use the --amend option of <a href="git-commit.html">git-commit(1)</a> on a change you've

 already dcommitted.  It is considered bad practice to --amend commits

 you've already pushed to a remote repository for other users, and

 dcommit with SVN is analogous to that.</p>

@@ -1137,7 +1137,7 @@ for git to detect them.</p>
 </div>

 <h2>CONFIGURATION</h2>

 <div class="sectionbody">

-<p>git-svn stores [svn-remote] configuration information in the

+<p><tt>git-svn</tt> stores [svn-remote] configuration information in the

 repository .git/config file.  It is similar the core git

 [remote] sections except <em>fetch</em> keys do not accept glob

 arguments; but they are instead handled by the <em>branches</em>

@@ -1157,8 +1157,7 @@ listed below are allowed:</p>
 however the remote wildcard may be anywhere as long as it's own

 independent path component (surrounded by <em>/</em> or EOL).   This

 type of configuration is not automatically created by <em>init</em> and

-should be manually entered with a text-editor or using

-<a href="git-config.html">git-config(1)</a></p>

+should be manually entered with a text-editor or using <tt>git-config</tt>.</p>

 </div>

 <h2>SEE ALSO</h2>

 <div class="sectionbody">

@@ -1174,7 +1173,7 @@ should be manually entered with a text-editor or using
 </div>

 <div id="footer">

 <div id="footer-text">

-Last updated 29-Jun-2008 08:48:21 UTC

+Last updated 02-Jul-2008 03:02:04 UTC

 </div>

 </div>

 </body>