Re: using git-svn with --no-metadata

Vadim Zeitlin [off-list ref] wrote:

 Just in case you're curious, let me describe the problem I have with
commit rewriting. First, my setup is such that I have a single git-svn
clone (under Linux) but as most of the projects I'm working on are
cross-platform I also have git clones of this repository under Windows, Mac
&c. And when I implement some feature under, say, Windows, on a branch
win-work I then push it to Linux machine (where I can test that it didn't
break anything under Unix) and then use "git svn dcommit" from there. So
far all is well but the problem is that when I update my Windows repository
master branch, it has different commits from the ones on win-work branch.
So I can't e.g. "git branch -d win-work" but need to use "branch -D" (if I
am perfectly sure I committed everything) or, usually, "git rebase master
win-work" and only then delete the branch after git tells me that there are
no differences left.

 All this is hardly catastrophic but if I could avoid it somehow it would
be even better. Now that I know that "svn clone --no-metadata" won't help
me with this I wonder if the others have any better ways of working in such
setup?

I've favored a rebase-heavy workflow for many years now.  When working
with SVN, I found "git svn rebase" much more convenient to use than
normal "git rebase".  I'm not at all hesitant with "branch -D" since I
know reflogs/fsck will protect me from mistakes.

On pure git workflows, I still use rebase often and mail patches to
myself to transfer works-in-progress between machines.  If the machines
don't have a properly configured MTA, then I use format-patch and scp
patches/mboxes around.

 Sorry if I sound like a broken record but this still seems to be unclear
to me for the same reasons as the original text, i.e. because there is
still the "if you lose ... then you won't be able to fetch again"
implication (at least to me). Wouldn't something like

	This option can only be used for one-shot imports as 'git svn'
	will not be able to fetch again without metadata. Additionally,
	if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not
	be able to rebuild them.

be more clear?

Yes, much better.  I'll use your words instead :>

From b7ddc7100f897d5b6a661a4aa57948608e4c3585 Mon Sep 17 00:00:00 2001

From: Eric Wong <redacted>
Date: Sat, 21 Aug 2010 18:52:14 +0000
Subject: [PATCH] Documentation/git-svn: discourage "noMetadata"

"noMetadata" is a sometimes harmful option, so better document
its behavior and limitations.

Suggested-by: Vadim Zeitlin
Signed-off-by: Eric Wong <redacted>
---
 Documentation/git-svn.txt |   17 ++++++++++++++---
 1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 4b84d08..be8a51f 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt

@@ -56,6 +56,8 @@ COMMANDS
 	as well, they take precedence.
 --no-metadata;;
 	Set the 'noMetadata' option in the [svn-remote] config.
+	This option is not recommended, please read the 'svn.noMetadata'
+	section of this manpage before using this option.
 --use-svm-props;;
 	Set the 'useSvmProps' option in the [svn-remote] config.
 --use-svnsync-props;;

@@ -597,13 +599,22 @@ svn.noMetadata::
 svn-remote.<name>.noMetadata::
 	This gets rid of the 'git-svn-id:' lines at the end of every commit.
 +
-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.
+This option can only be used for one-shot imports as 'git svn'
+will not be able to fetch again without metadata. Additionally,
+if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not
+be able to rebuild them.
 +
 The 'git svn log' command will not work on repositories using
 this, either.  Using this conflicts with the 'useSvmProps'
 option for (hopefully) obvious reasons.
++
+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
+and are certain about dropping SVN history, consider
+linkgit:git-filter-branch[1] instead.  filter-branch also allows
+reformating of metadata for ease-of-reading and rewriting authorship
+info for non-"svn.authorsFile" users.
 
 svn.useSvmProps::
 svn-remote.<name>.useSvmProps::

-- 
Eric Wong