<div class="sectionbody">\r
<p>Clones a repository into a newly created directory, creates\r
remote-tracking branches for each branch in the cloned repository\r
-(visible using <tt>git branch -r</tt>), and creates and checks out a master\r
-branch equal to the cloned repository's master branch.</p>\r
+(visible using <tt>git branch -r</tt>), and creates and checks out an initial\r
+branch equal to the cloned repository's currently active branch.</p>\r
<p>After the clone, a plain <tt>git fetch</tt> without arguments will update\r
all the remote-tracking branches, and a <tt>git pull</tt> without\r
arguments will in addition merge the remote master branch into the\r
-current branch.</p>\r
+current master branch, if any.</p>\r
<p>This default configuration is achieved by creating references to\r
the remote branch heads under <tt>$GIT_DIR/refs/remotes/origin</tt> and\r
by initializing <tt>remote.origin.url</tt> and <tt>remote.origin.fetch</tt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 02-Jan-2007 00:04:07 UTC\r
+Last updated 07-Jan-2007 07:43:48 UTC\r
</div>\r
</div>\r
</body>\r
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
-(visible using `git branch -r`), and creates and checks out a master
-branch equal to the cloned repository's master branch.
+(visible using `git branch -r`), and creates and checks out an initial
+branch equal to the cloned repository's currently active branch.
After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
arguments will in addition merge the remote master branch into the
-current branch.
+current master branch, if any.
This default configuration is achieved by creating references to
the remote branch heads under `$GIT_DIR/refs/remotes/origin` and
</dt>\r
<dd>\r
<p>\r
- Commit all diffs from a specified head directly to the SVN\r
+ Commit each diff from a specified head directly to the SVN\r
repository, and then rebase or reset (depending on whether or\r
- not there is a diff between SVN and head). It is recommended\r
- that you run git-svn fetch and rebase (not pull) your commits\r
- against the latest changes in the SVN repository.\r
+ not there is a diff between SVN and head). This will create\r
+ a revision in SVN for each commit in git.\r
+ It is recommended that you run git-svn fetch and rebase (not\r
+ pull or merge) your commits against the latest changes in the\r
+ SVN repository.\r
An optional command-line argument may be specified as an\r
alternative to HEAD.\r
This is advantageous over <em>set-tree</em> (below) because it produces\r
git-svn multi-init</tt></pre>\r
</div></div>\r
</div>\r
-<h2>REBASE VS. PULL</h2>\r
+<h2>REBASE VS. PULL/MERGE</h2>\r
<div class="sectionbody">\r
<p>Originally, git-svn recommended that the remotes/git-svn branch be\r
-pulled from. This is because the author favored <em>git-svn set-tree B</em>\r
-to commit a single head rather than the <em>git-svn set-tree A..B</em> notation\r
-to commit multiple commits.</p>\r
-<p>If you use <em>git-svn set-tree A..B</em> to commit several diffs and you do not\r
-have the latest remotes/git-svn merged into my-branch, you should use\r
-<em>git rebase</em> to update your work branch instead of <em>git pull</em>. <em>pull</em>\r
-can cause non-linear history to be flattened when committing into SVN,\r
-which can lead to merge commits reversing previous commits in SVN.</p>\r
+pulled or merged from. This is because the author favored\r
+<em>git-svn set-tree B</em> to commit a single head rather than the\r
+<em>git-svn set-tree A..B</em> notation to commit multiple commits.</p>\r
+<p>If you use <em>git-svn set-tree A..B</em> to commit several diffs and you do\r
+not have the latest remotes/git-svn merged into my-branch, you should\r
+use <em>git rebase</em> to update your work branch instead of <em>git pull</em> or\r
+<em>git merge</em>. <em>pull/merge</em> can cause non-linear history to be flattened\r
+when committing into SVN, which can lead to merge commits reversing\r
+previous commits in SVN.</p>\r
</div>\r
<h2>DESIGN PHILOSOPHY</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 05-Jan-2007 07:46:19 UTC\r
+Last updated 07-Jan-2007 07:43:50 UTC\r
</div>\r
</div>\r
</body>\r
manually joining branches on commit.
'dcommit'::
- Commit all diffs from a specified head directly to the SVN
+ Commit each diff from a specified head directly to the SVN
repository, and then rebase or reset (depending on whether or
- not there is a diff between SVN and head). It is recommended
- that you run git-svn fetch and rebase (not pull) your commits
- against the latest changes in the SVN repository.
+ 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
+ pull or merge) your commits against the latest changes in the
+ SVN repository.
An optional command-line argument may be specified as an
alternative to HEAD.
This is advantageous over 'set-tree' (below) because it produces
git-svn multi-init
------------------------------------------------------------------------
-REBASE VS. PULL
----------------
+REBASE VS. PULL/MERGE
+---------------------
Originally, git-svn recommended that the remotes/git-svn branch be
-pulled from. This is because the author favored 'git-svn set-tree B'
-to commit a single head rather than the 'git-svn set-tree A..B' notation
-to commit multiple commits.
-
-If you use 'git-svn set-tree A..B' to commit several diffs and you do not
-have the latest remotes/git-svn merged into my-branch, you should use
-'git rebase' to update your work branch instead of 'git pull'. 'pull'
-can cause non-linear history to be flattened when committing into SVN,
-which can lead to merge commits reversing previous commits in SVN.
+pulled or merged from. This is because the author favored
+'git-svn set-tree B' to commit a single head rather than the
+'git-svn set-tree A..B' notation to commit multiple commits.
+
+If you use 'git-svn set-tree A..B' to commit several diffs and you do
+not have the latest remotes/git-svn merged into my-branch, you should
+use 'git rebase' to update your work branch instead of 'git pull' or
+'git merge'. 'pull/merge' can cause non-linear history to be flattened
+when committing into SVN, which can lead to merge commits reversing
+previous commits in SVN.
DESIGN PHILOSOPHY
-----------------
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]\r
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]\r
[ -I <ignorefile_name> ] [ -A <author_file> ]\r
- [ -P <path_from_trunk> ]\r
+ [ -R <repack_each_revs>] [ -P <path_from_trunk> ]\r
<SVN_repository_URL> [ <path> ]</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
due to SVN memory leaks. (These have been worked around.)</p>\r
</dd>\r
<dt>\r
+-R <repack_each_revs>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Specify how often git repository should be repacked.\r
+</p>\r
+<p>The default value is 1000. git-svnimport will do import in chunks of 1000\r
+revisions, after each chunk git repository will be repacked. To disable\r
+this behavior specify some big value here which is mote than number of\r
+revisions to import.</p>\r
+</dd>\r
+<dt>\r
-P <path_from_trunk>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 17-Dec-2006 19:31:44 UTC\r
+Last updated 07-Jan-2007 07:43:49 UTC\r
</div>\r
</div>\r
</body>\r
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
- [ -P <path_from_trunk> ]
+ [ -
R <repack_each_revs>] [ -P <path_from_trunk> ]
<SVN_repository_URL> [ <path> ]
Formerly, this option controlled how many revisions to pull,
due to SVN memory leaks. (These have been worked around.)
+-R <repack_each_revs>::
+ Specify how often git repository should be repacked.
++
+The default value is 1000. git-svnimport will do import in chunks of 1000
+revisions, after each chunk git repository will be repacked. To disable
+this behavior specify some big value here which is mote than number of
+revisions to import.
+
-P <path_from_trunk>::
Partial import of the SVN tree.
+
</div></div>\r
<p>You've now initialized the working directory—you may notice a new\r
directory created, named ".git". Tell git that you want it to track\r
-every file under the current directory with (notice the dot <em>.</em>\r
-that means the current directory):</p>\r
+every file under the current directory (note the <em>.</em>) with:</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git add .</tt></pre>\r
</div></div>\r
<p>will prompt you for a commit message, then record the current state\r
of all the files to the repository.</p>\r
+</div>\r
+<h2>Making changes</h2>\r
+<div class="sectionbody">\r
<p>Try modifying some files, then run</p>\r
<div class="listingblock">\r
<div class="content">\r
make a commit, like this:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git add file1 file...\r
+<pre><tt>$ git add file1 file2 file3\r
$ git commit</tt></pre>\r
</div></div>\r
<p>This will again prompt your for a message describing the change, and then\r
-record the new versions of the files you listed. It is cumbersome\r
-to list all files and you can say <tt>git commit -a</tt> (which stands for <em>all</em>)\r
-instead of running <tt>git add</tt> beforehand.</p>\r
+record the new versions of the files you listed.</p>\r
+<p>Alternatively, instead of running <tt>git add</tt> beforehand, you can use</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git commit -a</tt></pre>\r
</div></div>\r
+<p>which will automatically notice modified (but not new) files.</p>\r
<p>A note on commit messages: Though not required, it's a good idea to\r
begin the commit message with a single short (less than 50 character)\r
line summarizing the change, followed by a blank line and then a more\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Jan-2007 22:02:04 UTC\r
+Last updated 07-Jan-2007 07:43:51 UTC\r
</div>\r
</div>\r
</body>\r
You've now initialized the working directory--you may notice a new
directory created, named ".git". Tell git that you want it to track
-every file under the current directory with (notice the dot '.'
-that means the current directory):
+every file under the current directory (note the '.') with:
------------------------------------------------
$ git add .
will prompt you for a commit message, then record the current state
of all the files to the repository.
+Making changes
+--------------
+
Try modifying some files, then run
------------------------------------------------
make a commit, like this:
------------------------------------------------
-$ git add file1 file...
+$ git add file1 file2 file3
$ git commit
------------------------------------------------
This will again prompt your for a message describing the change, and then
-record the new versions of the files you listed. It is cumbersome
-to list all files and you can say `git commit -a` (which stands for 'all')
-instead of running `git add` beforehand.
+record the new versions of the files you listed.
+
+Alternatively, instead of running `git add` beforehand, you can use
------------------------------------------------
$ git commit -a
------------------------------------------------
+which will automatically notice modified (but not new) files.
+
A note on commit messages: Though not required, it's a good idea to
begin the commit message with a single short (less than 50 character)
line summarizing the change, followed by a blank line and then a more
projects / git.git / commitdiff