2

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---r4---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?

RobM
  • 8,373
  • 3
  • 45
  • 37

2 Answers2

3

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)

RobM
  • 8,373
  • 3
  • 45
  • 37
0

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.

Dmitry Pavlenko
  • 8,530
  • 3
  • 30
  • 38