Autogenerated HTML docs for v1.8.1.2-545-g2f19ad

1 files changed, 45 insertions, 45 deletions

diff --git a/git-svn.html b/git-svn.html
index fc82c6f69..f473f438b 100644
--- a/git-svn.html
+++ b/git-svn.html
@@ -737,7 +737,7 @@ git-svn(1) Manual Page
 <h2>NAME</h2>

 <div class="sectionbody">

 <p>git-svn -

-   Bidirectional operation between a Subversion repository and git

+   Bidirectional operation between a Subversion repository and Git

 </p>

 </div>

 </div>

@@ -754,16 +754,16 @@ git-svn(1) Manual Page
 <div class="sect1">

 <h2 id="_description">DESCRIPTION</h2>

 <div class="sectionbody">

-<div class="paragraph"><p><em>git svn</em> is a simple conduit for changesets between Subversion and git.

-It provides a bidirectional flow of changes between a Subversion and a git

+<div class="paragraph"><p><em>git svn</em> is a simple conduit for changesets between Subversion and Git.

+It provides a bidirectional flow of changes between a Subversion and a Git

 repository.</p></div>

 <div class="paragraph"><p><em>git svn</em> can track a standard Subversion repository,

 following the common "trunk/branches/tags" layout, with the --stdlayout option.

 It can also follow branches and tags in any layout with the -T/-t/-b options

 (see options to <em>init</em> below, and also the <em>clone</em> command).</p></div>

-<div class="paragraph"><p>Once tracking a Subversion repository (with any of the above methods), the git

+<div class="paragraph"><p>Once tracking a Subversion repository (with any of the above methods), the Git

 repository can be updated from Subversion by the <em>fetch</em> command and

-Subversion updated from git by the <em>dcommit</em> command.</p></div>

+Subversion updated from Git by the <em>dcommit</em> command.</p></div>

 </div>

 </div>

 <div class="sect1">

@@ -775,7 +775,7 @@ Subversion updated from git by the <em>dcommit</em> command.</p></div>
 </dt>

 <dd>

 <p>

-        Initializes an empty git repository with additional

+        Initializes an empty Git repository with additional

         metadata directories for <em>git svn</em>.  The Subversion URL

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

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

@@ -1087,9 +1087,9 @@ and have no uncommitted changes.</p></div>
         Commit each diff from the current branch directly to the SVN

         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.

+        a revision in SVN for each commit in Git.

 </p>

-<div class="paragraph"><p>When an optional git branch name (or a git commit object name)

+<div class="paragraph"><p>When an optional Git branch name (or a Git commit object name)

 is specified as an argument, the subcommand works on the specified

 branch, not on the current branch.</p></div>

 <div class="paragraph"><p>Use of <em>dcommit</em> is preferred to <em>set-tree</em> (below).</p></div>

@@ -1309,7 +1309,7 @@ git config --get-all svn-remote.&lt;name&gt;.tags</code></pre>
 </dt>

 <dd>

 <p>

-        shows the git commit sha1, as well

+        shows the Git commit sha1, as well

 </p>

 </dd>

 <dt class="hdlist1">

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

 <p>

         Produce output in the same format as <em>git blame</em>, but with

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

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

         changes that haven&#8217;t been committed to SVN (including local

         working-copy edits) are shown as revision 0.

 </p>

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

 <p>

         When given an SVN revision number of the form <em>rN</em>, returns the

-        corresponding git commit hash (this can optionally be followed by a

+        corresponding Git commit hash (this can optionally be followed by a

         tree-ish to specify which branch should be searched).  When given a

         tree-ish, returns the corresponding SVN revision number.

 </p>

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

 <dd>

 <p>

-        Attempts to recreate empty directories that core git cannot track

+        Attempts to recreate empty directories that core Git cannot track

         based on information in $GIT_DIR/svn/&lt;refname&gt;/unhandled.log files.

         Empty directories are automatically recreated when using

         "git svn clone" and "git svn rebase", so "mkdirs" is intended

@@ -1649,9 +1649,9 @@ order.  Only the leading sha1 is read from each line, so
 </p>

 <div class="paragraph"><p>Remove directories from the SVN tree if there are no files left

 behind.  SVN can version empty directories, and they are not

-removed by default if there are no files left in them.  git

+removed by default if there are no files left in them.  Git

 cannot version empty directories.  Enabling this flag will make

-the commit to SVN act like git.</p></div>

+the commit to SVN act like Git.</p></div>

 <div class="verseblock">

 <pre class="content">config key: svn.rmdir</pre>

 <div class="attribution">

@@ -1798,7 +1798,7 @@ config key: svn.repackflags</pre>
         This can be used with the <em>dcommit</em>, <em>rebase</em>, <em>branch</em> and

         <em>tag</em> commands.

 </p>

-<div class="paragraph"><p>For <em>dcommit</em>, print out the series of git arguments that would show

+<div class="paragraph"><p>For <em>dcommit</em>, print out the series of Git arguments that would show

 which diffs would be committed to SVN.</p></div>

 <div class="paragraph"><p>For <em>rebase</em>, display the local branch associated with the upstream svn

 repository associated with the current branch and the URL of svn

@@ -1811,7 +1811,7 @@ creating the branch or tag.</p></div>
 </dt>

 <dd>

 <p>

-        When retrieving svn commits into git (as part of <em>fetch</em>, <em>rebase</em>, or

+        When retrieving svn commits into Git (as part of <em>fetch</em>, <em>rebase</em>, or

         <em>dcommit</em> operations), look for the first <code>From:</code> or <code>Signed-off-by:</code> line

         in the log message and use that as the author string.

 </p>

@@ -1821,10 +1821,10 @@ creating the branch or tag.</p></div>
 </dt>

 <dd>

 <p>

-        When committing to svn from git (as part of <em>commit-diff</em>, <em>set-tree</em> or <em>dcommit</em>

+        When committing to svn from Git (as part of <em>commit-diff</em>, <em>set-tree</em> or <em>dcommit</em>

         operations), if the existing log message doesn&#8217;t already have a

         <code>From:</code> or <code>Signed-off-by:</code> line, append a <code>From:</code> line based on the

-        git commit&#8217;s author string.  If you use this, then <code>--use-log-author</code>

+        Git commit&#8217;s author string.  If you use this, then <code>--use-log-author</code>

         will retrieve a valid author string for all commits.

 </p>

 </dd>

@@ -1871,7 +1871,7 @@ creating the branch or tag.</p></div>
         one of the repository layout options --trunk, --tags,

         --branches, --stdlayout). For each tracked branch, try to find

         out where its revision was copied from, and set

-        a suitable parent in the first git commit for the branch.

+        a suitable parent in the first Git commit for the branch.

         This is especially helpful when we&#8217;re tracking a directory

         that has been moved around within the repository.  If this

         feature is disabled, the branches created by <em>git svn</em> will all

@@ -1913,7 +1913,7 @@ this, either.  Using this conflicts with the <em>useSvmProps</em>
 option for (hopefully) obvious reasons.</p></div>

 <div class="paragraph"><p>This option is NOT recommended as it makes it difficult to track down

 old references to SVN revision numbers in existing documentation, bug

-reports and archives.  If you plan to eventually migrate from SVN to git

+reports and archives.  If you plan to eventually migrate from SVN to Git

 and are certain about dropping SVN history, consider

 <a href="git-filter-branch.html">git-filter-branch(1)</a> instead.  filter-branch also allows

 reformatting of metadata for ease-of-reading and rewriting authorship

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

 <dd>

 <p>

-        Similar to git&#8217;s <em>remote.&lt;name&gt;.pushurl</em>, this key is designed

+        Similar to Git&#8217;s <em>remote.&lt;name&gt;.pushurl</em>, this key is designed

         to be used in cases where <em>url</em> points to an SVN repository

         via a read-only transport, to provide an alternate read/write

         transport. It is assumed that both keys point to the same

@@ -2049,15 +2049,15 @@ for rewriteRoot and rewriteUUID which can be used together.</p></div>
         cd trunk

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

         git branch

-# Do some work and commit locally to git:

+# Do some work and commit locally to Git:

         git commit ...

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

 # latest changes in SVN:

         git svn rebase

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

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

 # as well as automatically updating your working HEAD:

         git svn dcommit

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

+# Append svn:ignore settings to the default Git exclude file:

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

 </div></div>

 <div class="paragraph"><p>Tracking and contributing to an entire Subversion-managed project

@@ -2095,7 +2095,7 @@ have each person clone that repository with <em>git clone</em>:</p></div>
         git remote add origin server:/pub/project

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

         git fetch

-# Prevent fetch/pull from remote git server in the future,

+# Prevent fetch/pull from remote Git server in the future,

 # we only want to use git svn for future updates

         git config --remove-section remote.origin

 # Create a local branch from one of the branches just fetched

@@ -2131,7 +2131,7 @@ commits unexpectedly reversing previous commits in SVN.</p></div>
 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

-users keep history as linear as possible inside git to ease

+users keep history as linear as possible inside Git to ease

 compatibility with SVN (see the CAVEATS section below).</p></div>

 </div>

 </div>

@@ -2139,7 +2139,7 @@ compatibility with SVN (see the CAVEATS section below).</p></div>
 <h2 id="_handling_of_svn_branches">HANDLING OF SVN BRANCHES</h2>

 <div class="sectionbody">

 <div class="paragraph"><p>If <em>git svn</em> is configured to fetch branches (and --follow-branches

-is in effect), it sometimes creates multiple git branches for one

+is in effect), it sometimes creates multiple Git branches for one

 SVN branch, where the addtional branches have names of the form

 <em>branchname@nnn</em> (with nnn an SVN revision number).  These additional

 branches are created if <em>git svn</em> cannot find a parent commit for the

@@ -2148,17 +2148,17 @@ the other branches.</p></div>
 <div class="paragraph"><p>Normally, the first commit in an SVN branch consists

 of a copy operation. <em>git svn</em> will read this commit to get the SVN

 revision the branch was created from. It will then try to find the

-git commit that corresponds to this SVN revision, and use that as the

+Git commit that corresponds to this SVN revision, and use that as the

 parent of the branch. However, it is possible that there is no suitable

-git commit to serve as parent.  This will happen, among other reasons,

+Git commit to serve as parent.  This will happen, among other reasons,

 if the SVN branch is a copy of a revision that was not fetched by <em>git

 svn</em> (e.g. because it is an old revision that was skipped with

 <em>--revision</em>), or if in SVN a directory was copied that is not tracked

 by <em>git svn</em> (such as a branch that is not tracked at all, or a

 subdirectory of a tracked branch). In these cases, <em>git svn</em> will still

-create a git branch, but instead of using an existing git commit as the

+create a Git branch, but instead of using an existing Git commit as the

 parent of the branch, it will read the SVN history of the directory the

-branch was copied from and create appropriate git commits.  This is

+branch was copied from and create appropriate Git commits.  This is

 indicated by the message "Initializing parent: &lt;branchname&gt;".</p></div>

 <div class="paragraph"><p>Additionally, it will create a special branch named

 <em>&lt;branchname&gt;@&lt;SVN-Revision&gt;</em>, where &lt;SVN-Revision&gt; is the SVN revision

@@ -2166,14 +2166,14 @@ number the branch was copied from.  This branch will point to the newly
 created parent commit of the branch.  If in SVN the branch was deleted

 and later recreated from a different version, there will be multiple

 such branches with an <em>@</em>.</p></div>

-<div class="paragraph"><p>Note that this may mean that multiple git commits are created for a

+<div class="paragraph"><p>Note that this may mean that multiple Git commits are created for a

 single SVN revision.</p></div>

 <div class="paragraph"><p>An example: in an SVN repository with a standard

 trunk/tags/branches layout, a directory trunk/sub is created in r.100.

 In r.200, trunk/sub is branched by copying it to branches/. <em>git svn

-clone -s</em> will then create a branch <em>sub</em>. It will also create new git

+clone -s</em> will then create a branch <em>sub</em>. It will also create new Git

 commits for r.100 through r.199 and use these as the history of branch

-<em>sub</em>. Thus there will be two git commits for each revision from r.100

+<em>sub</em>. Thus there will be two Git commits for each revision from r.100

 to r.199 (one containing trunk/, one containing trunk/sub/). Finally,

 it will create a branch <em>sub@200</em> pointing to the new parent commit of

 branch <em>sub</em> (i.e. the commit for r.200 and trunk/sub/).</p></div>

@@ -2185,12 +2185,12 @@ branch <em>sub</em> (i.e. the commit for r.200 and trunk/sub/).</p></div>
 <div class="paragraph"><p>For the sake of simplicity and interoperating with Subversion,

 it is recommended that all <em>git svn</em> users clone, fetch and dcommit

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

-operations between git repositories and branches.  The recommended

-method of exchanging code between git branches and users is

+operations between Git repositories and branches.  The recommended

+method of exchanging code between Git branches and users is

 <em>git format-patch</em> and <em>git am</em>, or just 'dcommit&#8217;ing to the SVN repository.</p></div>

 <div class="paragraph"><p>Running <em>git merge</em> or <em>git pull</em> is NOT recommended on a branch you

 plan to <em>dcommit</em> from because Subversion users cannot see any

-merges you&#8217;ve made.  Furthermore, if you merge or pull from a git branch

+merges you&#8217;ve made.  Furthermore, if you merge or pull from a Git branch

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

 branch.</p></div>

 <div class="paragraph"><p>If you do merge, note the following rule: <em>git svn dcommit</em> will

@@ -2207,7 +2207,7 @@ the same SVN branch.</p></div>
 any <em>git svn</em> metadata, or config.  So repositories created and managed with

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

 at all.</p></div>

-<div class="paragraph"><p>Since <em>dcommit</em> uses rebase internally, any git branches you <em>git push</em> to

+<div class="paragraph"><p>Since <em>dcommit</em> uses rebase internally, any Git branches you <em>git push</em> 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 <a href="git-push.html">git-push(1)</a> documentation for details.</p></div>

@@ -2217,7 +2217,7 @@ you&#8217;ve already pushed to a remote repository for other users, and
 dcommit with SVN is analogous to that.</p></div>

 <div class="paragraph"><p>When cloning an SVN repository, if none of the options for describing

 the repository layout is used (--trunk, --tags, --branches,

---stdlayout), <em>git svn clone</em> will create a git repository with

+--stdlayout), <em>git svn clone</em> will create a Git repository with

 completely linear history, where branches and tags appear as separate

 directories in the working copy.  While this is the easiest way to get a

 copy of a complete repository, for projects with many branches it will

@@ -2232,7 +2232,7 @@ branches and tags is required, the options <em>--trunk</em> / <em>--branches</em
 <div class="paragraph"><p>When using multiple --branches or --tags, <em>git svn</em> does not automatically

 handle name collisions (for example, if two branches from different paths have

 the same name, or if a branch and a tag have the same name).  In these cases,

-use <em>init</em> to set up your git repository then, before your first <em>fetch</em>, edit

+use <em>init</em> to set up your Git repository then, before your first <em>fetch</em>, edit

 the .git/config file so that the branches and tags are associated with

 different name spaces.  For example:</p></div>

 <div class="literalblock">

@@ -2247,12 +2247,12 @@ branches = debug/*:refs/remotes/svn/debug/*</code></pre>
 <div class="sectionbody">

 <div class="paragraph"><p>We ignore all SVN properties except svn:executable.  Any unhandled

 properties are logged to $GIT_DIR/svn/&lt;refname&gt;/unhandled.log</p></div>

-<div class="paragraph"><p>Renamed and copied directories are not detected by git and hence not

+<div class="paragraph"><p>Renamed and copied directories are not detected by Git and hence not

 tracked when committing to SVN.  I do not plan on adding support for

 this as it&#8217;s quite difficult and time-consuming to get working for all

-the possible corner cases (git doesn&#8217;t do it, either).  Committing

+the possible corner cases (Git doesn&#8217;t do it, either).  Committing

 renamed and copied files is fully supported if they&#8217;re similar enough

-for git to detect them.</p></div>

+for Git to detect them.</p></div>

 <div class="paragraph"><p>In SVN, it is possible (though discouraged) to commit changes to a tag

 (because a tag is just a directory copy, thus technically the same as a

 branch). When cloning an SVN repository, <em>git svn</em> cannot know if such a

@@ -2264,7 +2264,7 @@ and imports all SVN tags as branches, prefixing the tag name with <em>tags/</em>
 <h2 id="_configuration">CONFIGURATION</h2>

 <div class="sectionbody">

 <div class="paragraph"><p><em>git svn</em> stores [svn-remote] configuration information in the

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

+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>

 and <em>tags</em> keys.  Since some SVN repositories are oddly

@@ -2316,7 +2316,7 @@ reset) branches-maxRev and/or tags-maxRev as appropriate.</p></div>
 <div id="footnotes"><hr /></div>

 <div id="footer">

 <div id="footer-text">

-Last updated 2013-01-18 13:06:16 PST

+Last updated 2013-02-05 21:07:26 PST

 </div>

 </div>

 </body>