git-svn dcommit exports commits to Subversion, then imports them back
to git again, and last but not least rebases or resets HEAD to the
last of the new commits. I guess this rebasing is convenient when
using just git, but when the commits to be exported are managed by
StGIT, it's really annoying. So add an option to disable this
behavior. And document it, too!
Signed-off-by: Karl Hasselström <kha@treskal.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some of the existing markup was just plain broken, and some subcommand
options weren't indented properly.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds a new 'find-rev' command to git-svn that lets you easily
translate between SVN revision numbers and git tree-ish.
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds a new 'find-rev' command to git-svn that lets you easily
translate between SVN revision numbers and git tree-ish.
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This avoids fetching new revisions remotely, and is usefuly
versus plain "git rebase" because the user does not have to
specify which remote head to rebase against.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix some formatting problems:
- Some list labels were missing their "::" characters.
- Some of continuation paragraphs in labeled lists were incorrectly
formatted as literal paragraphs.
- In one case "[verse]" was missing before the config key list.
- The "Basic Examples" section was incorrectly nested inside the
"Config File-Only Options" section.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, it turns out that SVN::Ra doesn't attempt to deal with
authentication or pass the username to ssh when doing svn+ssh://
URLs
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since the options that affect the way metadata is handled in
git-svn, should be consistently set/unset throughout history
imported by git-svn; it makes sense to allow the user to set
certain options from the command-line that will write to the
config file when initially creating the repository.
Also, fix some formatting issues while we're updating
documentation.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This documents the 'clone' and 'rebase' commands
of git-svn. Additionaly, examples are updated
to use them instead of the lower-level 'init' and
'fetch' commands.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Force the showing of the --minimize flag as an option in the
'migrate' help.
Also, fix the usage function to correctly filter out
the deprecated aliases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Make sure we flush our userspace buffers and and fsync(2)
.rev_db information to disk if we use these options because
we really don't want to lose this information.
Also, disallow --use-svm-props and --no-metadata from the
command-line because history will be inconsistent if they're
only used occasionally. If a user wants to use these options,
they must be set in the config so they're always on.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--no-follow-parent disables and reverts it back to the old
default behavior of not following parents (if you don't care for
full history).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--svn-remote allows the default remote name to be overridden (useful
for tracking multiple SVN repositories).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since refs/remotes/* are not automatically cloned, we expect the
user to be capable of copying those references themselves
anyways.
Also removed the documentation for --ignore-nodate while we're
at it; it has also been made automatic.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It's not really useful anymore now that we have a better
--follow-parent for the valid cases. Any other use
of it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
While 'init-db' still is and probably will always remain a valid git
command for obvious backward compatibility reasons, it would be a good
idea to move shipped tools and docs to using 'init' instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-svn requires the SVN::* Perl library, the manpage doesn't need
to describe what happens when you don't have it.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, document --{trunk,branches,tags} options while we're
documenting multi-init options.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clarify that dcommit creates a revision in SVN for every commit
in git. Also, add 'merge' to the rebase vs pull section because
git-merge is now a first-class UI.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
'set-tree' probably accurately describes what the command
formerly known as 'commit' does.
I'm not entirely sure that 'dcommit' should be renamed to 'commit'
just yet... Perhaps 'push' or 'push-changes'?
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously dcommit would unconditionally commit all patches
up-to and including the current HEAD. Now if an optional
command-line argument is specified, it will only commit
up to the specified revision.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Eliminate 'commit' from some places and plug 'dcommit' more.
Also update the section --id (GIT_SVN_ID) usage since we
have multi-init/multi-fetch now.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There was a bug in dcommit (and commit-diff) which caused deltas
to be generated against the latest version of the changed file
in a repository, and not the revision we are diffing (the tree)
against locally.
This bug can cause recent changes to the svn repository to be
silently clobbered by git-svn if our repository is out-of-date.
Thanks to Steven Grimm for noticing the bug.
The (few) people using the commit-diff command are now required
to use the -r/--revision argument. dcommit usage is unchanged.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've forgotten to document many of the features added along the
way in the manpages. This fills in some holes in the
documentation and adds updates some outdated information.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added --ignore-nodate to allow 'git svn fetch' to import revisions
from Subversion which have '(no date)' listed as the date of the
revision. By default 'git svn fetch' will crash with an error
when encountering such a revision. The user may restart the fetch
operation by adding --ignore-nodate if they want to continue tracking
that repository.
I'm not entirely sure why a centralized version control system such
as Subversion permits revisions to be created with absolutely no
date/time associated with it but it apparently is possible as one
of the Subversion repositories that I'm tracking with 'git svn'
created such a revision on '(no date)' and by '(no user)'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a high-level wrapper around the 'commit-diff' command
and used to produce cleaner history against the mirrored repository
through rebase/reset usage.
It's basically a more polished version of this:
for i in `git rev-list --no-merges remotes/git-svn..HEAD | tac`; do
git-svn commit-diff $i~1 $i
done
git reset --hard remotes/git-svn
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Does this make sense to other git-svn users out there?
pull can give funky history unless you understand how git-svn works
internally, which users should not be expected to do.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use list continuation to have better wrapping. This accounts for most of
the changes because it reindents a lot of text without applying other
changes.
Use cross-referencing for interlinking and the gitlink macro for pointing
to other tools in the git suite.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow NO_SVN_TESTS to be defined to skip git-svn tests. These
tests are time-consuming due to SVN being slow, and even more so
if SVN Perl libraries are not available.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
