I'm using git-svn
to interact with a remote svn
repsitory that follows the traditional layout of trunk, tags, and branches.
There's a branch in svn
that git
has missed the history of. I know the history to be:
r0--r1--r2---开发者_如何学Cr4---r6 remotes/trunk
\
r3---r5-- remotes/BRANCH_NAME
But git seems to have missed the branch point and thinks the history is:
r0---r1---r2-----r4---r6 remotes/trunk
r0'--r1'--r2'--r3--r5--- remotes/BRANCH_NAME
Where r0'
, r1'
, and r2'
are copies of r0
, r1
, and r2
that appear in git, but not in svn. In svn there is exactly one r0
commit.
The first entry in .git/svn/refs/remotes/BRANCH_NAME/unhandled.log.gz
may offer the experts a clue:
r3
+dir_prop: . svn:mergeinfo /product/trunk/src_py:371-436%2C438-532
How do I get git to realise that r3
was branched from r2
and do away with r2'
, r1'
, and r0'
?
For extra credit: Is there a general way to rewrite git's view of svn history, that won't get clobbered by git svn fetch
et al?
It turned out to be the git-svn-id
URL in the log messages that was different, thus altering the SHA1. E.g. http://hostname/repo
and http://hostname.org.ext/repo
.
I used git branch-filter --msg-filter
to update the git-svn-id
marker in every commit and the problem went away. (And of course ran git gc
to scrub all the redundant commits from my repo)
I would recommend you to use SmartGit instead of git-svn. It handles such SHA1-changes correctly.
Or alternatively, if you have an access to the SVN serevr, install SubGit into it. SubGit will create a linked Git repository that you can work with. SVN and Git repositories will always be in sync. So you can use just Git interface.
精彩评论