Autogenerated HTML docs for v1.5.0.1-213-g509b

1 files changed, 267 insertions, 233 deletions

diff --git a/git-svn.html b/git-svn.html
index b4221ec5a..2fd6550c4 100644
--- a/git-svn.html
+++ b/git-svn.html
@@ -278,13 +278,12 @@ git-svn(1) Manual Page
 <div class="sectionbody">

 <p>git-svn 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 and geared towards tracking multiple branches.</p>

+read-only.</p>

 <p>git-svn 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; but it cannot (yet) automatically detect new

-branches and tags like git-svnimport does.</p>

+similar to git-svnimport.</p>

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

 not organized in the way Subversion developers recommend (trunk,

 branches, tags directories).</p>

@@ -297,29 +296,144 @@ branches, tags directories).</p>
 </dt>

 <dd>

 <p>

-        Creates an empty git repository with additional metadata

-        directories for git-svn.  The Subversion URL must be specified

-        as a command-line argument.  Optionally, the target directory

-        to operate on can be specified as a second argument.  Normally

-        this command initializes the current directory.

+        Initializes an empty git repository with additional

+        metadata directories for git-svn.  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

+        argument.  Normally this command initializes the current

+        directory.

 </p>

 </dd>

 <dt>

+-T&lt;trunk_subdir&gt;

+</dt>

+<dt>

+--trunk=&lt;trunk_subdir&gt;

+</dt>

+<dt>

+-t&lt;tags_subdir&gt;

+</dt>

+<dt>

+--tags=&lt;tags_subdir&gt;

+</dt>

+<dt>

+-b&lt;branches_subdir&gt;

+</dt>

+<dt>

+--branches=&lt;branches_subdir&gt;

+</dt>

+<dd>

+<p>

+        These are optional command-line options for init.  Each of

+        these flags can point to a relative repository path

+        (--tags=project/tags') or a full url

+        (--tags=https://foo.org/project/tags)

+</p>

+</dd>

+<dt>

+--no-metadata

+</dt>

+<dd>

+<p>

+        Set the <em>noMetadata</em> option in the [svn-remote] config.

+</p>

+</dd>

+<dt>

+--use-svm-props

+</dt>

+<dd>

+<p>

+        Set the <em>useSvmProps</em> option in the [svn-remote] config.

+</p>

+</dd>

+<dt>

+--use-svnsync-props

+</dt>

+<dd>

+<p>

+        Set the <em>useSvnsyncProps</em> option in the [svn-remote] config.

+</p>

+</dd>

+<dt>

+--rewrite-root=&lt;URL&gt;

+</dt>

+<dd>

+<p>

+        Set the <em>rewriteRoot</em> option in the [svn-remote] config.

+</p>

+</dd>

+<dt>

+--username=&lt;USER&gt;

+</dt>

+<dd>

+<p>

+        For transports that SVN handles authentication for (http,

+        https, and plain svn), specify the username.  For other

+        transports (eg svn+ssh://), you must include the username in

+        the URL, eg svn+ssh://foo@svn.bar.com/project

+</p>

+<p>--prefix=&lt;prefix&gt;

+        This allows one to specify a prefix which is prepended

+        to the names of remotes if trunk/branches/tags are

+        specified.  The prefix does not automatically include a

+        trailing slash, so be sure you include one in the

+        argument if that is what you want.  This is useful if

+        you wish to track multiple projects that share a common

+        repository.</p>

+</dd>

+<dt>

 <em>fetch</em>

 </dt>

 <dd>

 <p>

-Fetch unfetched revisions from the Subversion URL we are

-tracking.  refs/remotes/git-svn will be updated to the

-latest revision.

+        Fetch unfetched revisions from the Subversion remote we are

+        tracking.  The name of the [svn-remote "&#8230;"] section in the

+        .git/config file may be specified as an optional command-line

+        argument.

 </p>

-<p>Note: You should never attempt to modify the remotes/git-svn

-branch outside of git-svn.  Instead, create a branch from

-remotes/git-svn and work on that branch.  Use the <em>dcommit</em>

-command (see below) to write git commits back to

-remotes/git-svn.</p>

-<p>See <em><a href="#fetch-args">Additional Fetch Arguments</a></em> if you are interested in

-manually joining branches on commit.</p>

+</dd>

+<dt>

+<em>clone</em>

+</dt>

+<dd>

+<p>

+        Runs <em>init</em> and <em>fetch</em>.  It will automatically create a

+        directory based on the basename of the URL passed to it;

+        or if a second argument is passed; it will create a directory

+        and work within that.  It accepts all arguments that the

+        <em>init</em> and <em>fetch</em> commands accept; with the exception of

+        <em>--fetch-all</em>.   After a repository is cloned, the <em>fetch</em>

+        command will be able to update revisions without affecting

+        the working tree; and the <em>rebase</em> command will be able

+        to update the working tree with the latest changes.

+</p>

+</dd>

+<dt>

+<em>rebase</em>

+</dt>

+<dd>

+<p>

+        This fetches revisions from the SVN parent of the current HEAD

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

+</p>

+<div class="literalblock">

+<div class="content">

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

+it preserves linear history with 'git-rebase' instead of

+'git-merge' for ease of dcommit-ing with git-svn.</tt></pre>

+</div></div>

+<div class="literalblock">

+<div class="content">

+<pre><tt>This accepts all options that 'git-svn fetch' and 'git-rebase'

+accepts.  However '--fetch-all' only fetches from the current

+[svn-remote], and not all [svn-remote] definitions.</tt></pre>

+</div></div>

+<div class="literalblock">

+<div class="content">

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

+and have no uncommitted changes.</tt></pre>

+</div></div>

 </dd>

 <dt>

 <em>dcommit</em>

@@ -391,21 +505,6 @@ manually joining branches on commit.</p>
 </p>

 </dd>

 <dt>

-<em>rebuild</em>

-</dt>

-<dd>

-<p>

-        Not a part of daily usage, but this is a useful command if

-        you've just cloned a repository (using <a href="git-clone.html">git-clone(1)</a>) that was

-        tracked with git-svn.  Unfortunately, git-clone does not clone

-        git-svn metadata and the svn working tree that git-svn uses for

-        its operations.  This rebuilds the metadata so git-svn can

-        resume fetch operations.  A Subversion URL may be optionally

-        specified at the command-line if the directory/repository you're

-        tracking has moved or changed protocols.

-</p>

-</dd>

-<dt>

 <em>show-ignore</em>

 </dt>

 <dd>

@@ -431,82 +530,13 @@ manually joining branches on commit.</p>
         The -r&lt;revision&gt; option is required for this.

 </p>

 </dd>

-<dt>

-<em>graft-branches</em>

-</dt>

-<dd>

-<p>

-        This command attempts to detect merges/branches from already

-        imported history.  Techniques used currently include regexes,

-        file copies, and tree-matches).  This command generates (or

-        modifies) the $GIT_DIR/info/grafts file.  This command is

-        considered experimental, and inherently flawed because

-        merge-tracking in SVN is inherently flawed and inconsistent

-        across different repositories.

-</p>

-</dd>

-<dt>

-<em>multi-init</em>

-</dt>

-<dd>

-<p>

-        This command supports git-svnimport-like command-line syntax for

-        importing repositories that are laid out as recommended by the

-        SVN folks.  This is a bit more tolerant than the git-svnimport

-        command-line syntax and doesn't require the user to figure out

-        where the repository URL ends and where the repository path

-        begins.

-</p>

-</dd>

-<dt>

--T&lt;trunk_subdir&gt;

-</dt>

-<dt>

---trunk=&lt;trunk_subdir&gt;

-</dt>

-<dt>

--t&lt;tags_subdir&gt;

-</dt>

-<dt>

---tags=&lt;tags_subdir&gt;

-</dt>

-<dt>

--b&lt;branches_subdir&gt;

-</dt>

-<dt>

---branches=&lt;branches_subdir&gt;

-</dt>

-<dd>

-<p>

-        These are the command-line options for multi-init.  Each of

-        these flags can point to a relative repository path

-        (--tags=project/tags') or a full url

-        (--tags=https://foo.org/project/tags)

-</p>

-<p>--prefix=&lt;prefix&gt;

-        This allows one to specify a prefix which is prepended to the

-        names of remotes.  The prefix does not automatically include a

-        trailing slash, so be sure you include one in the argument if

-        that is what you want.  This is useful if you wish to track

-        multiple projects that share a common repository.</p>

-</dd>

-<dt>

-<em>multi-fetch</em>

-</dt>

-<dd>

-<p>

-        This runs fetch on all known SVN branches we're tracking.  This

-        will NOT discover new branches (unlike git-svnimport), so

-        multi-init will need to be re-run (it's idempotent).

-</p>

-</dd>

 </dl>

 </div>

 <h2>OPTIONS</h2>

 <div class="sectionbody">

 <dl>

 <dt>

---shared

+--shared[={false|true|umask|group|all|world|everybody}]

 </dt>

 <dt>

 --template=&lt;template_directory&gt;

@@ -525,13 +555,14 @@ manually joining branches on commit.</p>
 </dt>

 <dd>

 <p>

-Only used with the <em>fetch</em> command.

+Used with the <em>fetch</em> command.

 </p>

-<p>Takes any valid -r&lt;argument&gt; svn would accept and passes it

-directly to svn. -r&lt;ARG1&gt;:&lt;ARG2&gt; ranges and "{" DATE "}" syntax

-is also supported.  This is passed directly to svn, see svn

-documentation for more details.</p>

-<p>This can allow you to make partial mirrors when running fetch.</p>

+<p>This allows revision ranges for partial/cauterized history

+to be supported.  $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges),

+$NUMBER:HEAD, and BASE:$NUMBER are all supported.</p>

+<p>This can allow you to make partial mirrors when running fetch;

+but is generally not recommended because history will be skipped

+and lost.</p>

 </dd>

 <dt>

 -

@@ -661,7 +692,7 @@ config key: svn.repackflags</p>
 </dt>

 <dd>

 <p>

-These are only used with the <em>dcommit</em> command.

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

@@ -685,37 +716,30 @@ which diffs would be committed to SVN.</p>
 <div class="sectionbody">

 <dl>

 <dt>

--b&lt;refname&gt;

+-i&lt;GIT_SVN_ID&gt;

 </dt>

 <dt>

---branch &lt;refname&gt;

+--id &lt;GIT_SVN_ID&gt;

 </dt>

 <dd>

 <p>

-Used with <em>fetch</em>, <em>dcommit</em> or <em>set-tree</em>.

+This sets GIT_SVN_ID (instead of using the environment).  This

+allows the user to override the default refname to fetch from

+when tracking a single URL.  The <em>log</em> and <em>dcommit</em> commands

+no longer require this switch as an argument.

 </p>

-<p>This can be used to join arbitrary git branches to remotes/git-svn

-on new commits where the tree object is equivalent.</p>

-<p>When used with different GIT_SVN_ID values, tags and branches in

-SVN can be tracked this way, as can some merges where the heads

-end up having completely equivalent content.  This can even be

-used to track branches across multiple SVN _repositories_.</p>

-<p>This option may be specified multiple times, once for each

-branch.</p>

-<p>config key: svn.branch</p>

 </dd>

 <dt>

--i&lt;GIT_SVN_ID&gt;

+-R&lt;remote name&gt;

 </dt>

 <dt>

---id &lt;GIT_SVN_ID&gt;

+--svn-remote &lt;remote name&gt;

 </dt>

 <dd>

 <p>

-This sets GIT_SVN_ID (instead of using the environment).  See the

-section on

-<em><a href="#tracking-multiple-repos">Tracking Multiple Repositories or Branches</a></em>

-for more information on using GIT_SVN_ID.

+        Specify the [svn-remote "&lt;remote name&gt;"] section to use,

+        this allows SVN multiple repositories to be tracked.

+        Default: "svn"

 </p>

 </dd>

 <dt>

@@ -726,12 +750,21 @@ for more information on using GIT_SVN_ID.
         This is especially helpful when we're tracking a directory

         that has been moved around within the repository, or if we

         started tracking a branch and never tracked the trunk it was

-        descended from.

+        descended from. This feature is enabled by default, use

+        --no-follow-parent to disable it.

 </p>

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

 </dd>

+</dl>

+</div>

+<h2>CONFIG FILE-ONLY OPTIONS</h2>

+<div class="sectionbody">

+<dl>

 <dt>

---no-metadata

+svn.noMetadata

+</dt>

+<dt>

+svn-remote.&lt;name&gt;.noMetadata

 </dt>

 <dd>

 <p>

@@ -739,89 +772,105 @@ for more information on using GIT_SVN_ID.
 </p>

 <div class="literalblock">

 <div class="content">

-<pre><tt>With this, you lose the ability to use the rebuild command.  If

-you ever lose your .git/svn/git-svn/.rev_db file, you won't be

-able to fetch again, either.  This is fine for one-shot imports.</tt></pre>

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

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

+either.  This is fine for one-shot imports.</tt></pre>

 </div></div>

 <div class="literalblock">

 <div class="content">

-<pre><tt>The 'git-svn log' command will not work on repositories using this,

-either.</tt></pre>

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

+this, either.  Using this conflicts with the 'useSvmProps'

+option for (hopefully) obvious reasons.</tt></pre>

 </div></div>

-<p>config key: svn.nometadata</p>

 </dd>

-</dl>

-</div>

-<h2>COMPATIBILITY OPTIONS</h2>

-<div class="sectionbody">

-<dl>

 <dt>

---upgrade

+svn.useSvmProps

+</dt>

+<dt>

+svn-remote.&lt;name&gt;.useSvmProps

 </dt>

 <dd>

 <p>

-Only used with the <em>rebuild</em> command.

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

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

 </p>

-<p>Run this if you used an old version of git-svn that used

-"git-svn-HEAD" instead of "remotes/git-svn" as the branch

-for tracking the remote.</p>

+<div class="literalblock">

+<div class="content">

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

+that the revision was created by SVN::Mirror (also used by SVK).

+The property contains a repository UUID and a revision.  We want

+to make it look like we are mirroring the original URL, so

+introduce a helper function that returns the original identity

+URL and UUID, and use it when generating metadata in commit

+messages.</tt></pre>

+</div></div>

 </dd>

 <dt>

---ignore-nodate

+svn.useSvnsyncProps

+</dt>

+<dt>

+svn-remote.&lt;name&gt;.useSvnsyncprops

 </dt>

 <dd>

 <p>

-Only used with the <em>fetch</em> command.

+        Similar to the useSvmProps option; this is for users

+        of the svnsync(1) command distributed with SVN 1.4.x and

+        later.

 </p>

-<p>By default git-svn will crash if it tries to import a revision

-from SVN which has <em>(no date)</em> listed as the date of the revision.

-This is repository corruption on SVN's part, plain and simple.

-But sometimes you really need those revisions anyway.</p>

-<p>If supplied git-svn will convert <em>(no date)</em> entries to the UNIX

-epoch (midnight on Jan. 1, 1970).  Yes, that's probably very wrong.

-SVN was very wrong.</p>

+</dd>

+<dt>

+svn-remote.&lt;name&gt;.rewriteRoot

+</dt>

+<dd>

+<p>

+        This allows users to create repositories from alternate

+        URLs.  For example, an administrator could run git-svn 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.

+</p>

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

+options all affect the metadata generated and used by git-svn; 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

+section because they affect the <em>git-svn-id:</em> metadata line.</p>

 </dd>

 </dl>

 <h3>Basic Examples</h3>

 <p>Tracking and contributing to a the trunk of a Subversion-managed project:</p>

 <div class="listingblock">

 <div class="content">

-<pre><tt># Initialize a repo (like git init):

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

-# Fetch remote revisions:

-        git-svn fetch

-# Create your own branch to hack on:

-        git checkout -b my-branch remotes/git-svn

-# Do some work, and then commit your new changes to SVN, as well as

-# automatically updating your working HEAD:

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

+        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

+        git branch

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

+# as well as automatically updating your working HEAD:

         git-svn dcommit

-# Something is committed to SVN, rebase the latest into your branch:

-        git-svn fetch &amp;&amp; git rebase remotes/git-svn

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

         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):

-See also:

-<em><a href="#tracking-multiple-repos">Tracking Multiple Repositories or Branches</a></em></p>

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

 <div class="listingblock">

 <div class="content">

-<pre><tt># Initialize a repo (like git init):

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

-                -T trunk -b branches -t tags

-# Fetch remote revisions:

-        git-svn multi-fetch

-# Create your own branch of trunk to hack on:

-        git checkout -b my-trunk remotes/trunk

-# Do some work, and then commit your new changes to SVN, as well as

-# automatically updating your working HEAD:

-        git-svn dcommit -i trunk

-# Something has been committed to trunk, rebase the latest into your branch:

-        git-svn multi-fetch &amp;&amp; git rebase remotes/trunk

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

-        git-svn show-ignore -i trunk &gt;&gt; .git/info/exclude

-# Check for new branches and tags (no arguments are needed):

-        git-svn multi-init</tt></pre>

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

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

+# with the appropriate name):

+        git reset --hard remotes/trunk

+# You may only dcommit to one branch/tag/trunk at a time.  The usage

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

 </div></div>

 </div>

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

@@ -832,7 +881,7 @@ pulled or merged from.  This is because the author favored
 <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

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

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

+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

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

 previous commits in SVN.</p>

@@ -842,60 +891,45 @@ previous commits in SVN.</p>
 <p>Merge tracking in Subversion is lacking and doing branched development

 with Subversion is cumbersome as a result.  git-svn does not do

 automated merge/branch tracking by default and leaves it entirely up to

-the user on the git side.</p>

+the user on the git side.  git-svn does however follow copy

+history of the directory that it is tracking, however (much like

+how <em>svn log</em> works).</p>

 </div>

-<h2><a id="tracking-multiple-repos"></a>TRACKING MULTIPLE REPOSITORIES OR BRANCHES</h2>

+<h2>BUGS</h2>

 <div class="sectionbody">

-<p>Because git-svn does not care about relationships between different

-branches or directories in a Subversion repository, git-svn has a simple

-hack to allow it to track an arbitrary number of related _or_ unrelated

-SVN repositories via one git repository.  Simply use the --id/-i flag or

-set the GIT_SVN_ID environment variable to a name other other than

-"git-svn" (the default) and git-svn will ignore the contents of the

-$GIT_DIR/svn/git-svn directory and instead do all of its work in

-$GIT_DIR/svn/$GIT_SVN_ID for that invocation.  The interface branch will

-be remotes/$GIT_SVN_ID, instead of remotes/git-svn.  Any

-remotes/$GIT_SVN_ID branch should never be modified by the user outside

-of git-svn commands.</p>

+<p>We ignore all SVN properties except svn:executable.  Any unhandled

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

+<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's quite difficult and time-consuming to get working for all

+the possible corner cases (git doesn't do it, either).  Committing

+renamed and copied files are fully supported if they're similar enough

+for git to detect them.</p>

 </div>

-<h2><a id="fetch-args"></a>ADDITIONAL FETCH ARGUMENTS</h2>

+<h2>CONFIGURATION</h2>

 <div class="sectionbody">

-<p>This is for advanced users, most users should ignore this section.</p>

-<p>Unfetched SVN revisions may be imported as children of existing commits

-by specifying additional arguments to <em>fetch</em>.  Additional parents may

-optionally be specified in the form of sha1 hex sums at the

-command-line.  Unfetched SVN revisions may also be tied to particular

-git commits with the following syntax:</p>

+<p>git-svn 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>

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

+configured with multiple projects glob expansions such those

+listed below are allowed:</p>

 <div class="listingblock">

 <div class="content">

-<pre><tt>        svn_revision_number=git_commit_sha1</tt></pre>

+<pre><tt>[svn-remote "project-a"]

+        url = http://server.org/svn

+        branches = branches/*/project-a:refs/remotes/project-a/branches/*

+        tags = tags/*/project-a:refs/remotes/project-a/tags/*

+        trunk = trunk/project-a:refs/remotes/project-a/trunk</tt></pre>

 </div></div>

-<p>This allows you to tie unfetched SVN revision 375 to your current HEAD:</p>

-<div class="listingblock">

-<div class="content">

-<pre><tt>        git-svn fetch 375=$(git-rev-parse HEAD)</tt></pre>

-</div></div>

-<p>If you're tracking a directory that has moved, or otherwise been

-branched or tagged off of another directory in the repository and you

-care about the full history of the project, then you can use

-the --follow-parent option.</p>

-<div class="listingblock">

-<div class="content">

-<pre><tt>        git-svn fetch --follow-parent</tt></pre>

-</div></div>

-</div>

-<h2>BUGS</h2>

-<div class="sectionbody">

-<p>We ignore all SVN properties except svn:executable.  Too difficult to

-map them since we rely heavily on git write-tree being _exactly_ the

-same on both the SVN and git working trees and I prefer not to clutter

-working trees with metadata files.</p>

-<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's quite difficult and time-consuming to get working for all

-the possible corner cases (git doesn't do it, either).  Renamed and

-copied files are fully supported if they're similar enough for git to

-detect them.</p>

+<p>Keep in mind that the <em><strong></em> (asterisk) wildcard of the local ref

+(left of the <em>:</em>) *must</strong> be the farthest right path component;

+however the remote wildcard may be anywhere as long as it's own

+independent path componet (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>

 </div>

 <h2>SEE ALSO</h2>

 <div class="sectionbody">

@@ -911,7 +945,7 @@ detect them.</p>
 </div>

 <div id="footer">

 <div id="footer-text">

-Last updated 04-Feb-2007 08:31:45 UTC

+Last updated 23-Feb-2007 11:13:37 UTC

 </div>

 </div>

 </body>