Git svn rebase : checksum mismatch

Question

I have a problem when I try to do a git svn rebase on my repository. It displays :

Checksum mismatch: code/app/meta_appli/app_info.py
expected: d9cefed5d1a630273aa3742f7f414c83
     got: 4eb5f3506698bdcb64347b5237ada19f

I searched a lot but haven't found a way to solve this problem.

If anybody knows, please share your knowledge. Thanks in advance.

Answer 1

This solution was the only one that worked for me:

See what was the revision number of the last change on the file:

git svn log chrome/test/functional/search_engines.py

Reset svn to be closest parent before that revision:

git svn reset -r62248 -p

Do a git svn fetch!

Dance at your success.

Answer 2

Just happened to me, I run out of space in the middle of a "git svn dcommit" and after that I was getting the same message, "Checksum mismatch".

I just edited .git/refs/remotes/git-svn and replaced the id of the problematic commit with the previous one. Next rebase fixes the problem.

Answer 3

I encountered this error when I just specified branches but no trunk. When I specified one of the branches as trunk, there was no error any more when I retried. (The whole "trunk", "branch", "trunk" distinction is generally speaking a bit silly to enforce in git svn as they are just human conventions without any deeper technical meaning behind them in svn.)

Answer 4

I just did a git gc and then git svn rebase worked again.

Answer 5

In our practice the error "Checksum mismatch:" on .shtml files in git svn clone ... command was caused by the setup of the front-end Apache server to interpret the.shtml files (from SVN) as Server-Side Includes (SSI) and thus produce live content instead of just providing the stored file content. Disabling SSI in Apache's /etc/httpd.conf file for the period of migration by commenting out the

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

directives solved the problem.
Anyway, the migration of the repository could exclude some paths and files happens with:

git svn clone <URL> --ignore-paths=<regex>

clause. It makes sense to check the environment of the SVN server process if those files have special interpretation like SSI (and the .php and .py files) and disable it.

Answer 6

Additionnally to Domenic's answer (still svn-to-gitting in 2019…):

In the specific case of a deleted-then-recreated branch (1), reset should be applied to the branch creation commit, after having deleted references to the old branch:

> git svn fetch
…
r146970 = …
Checksum mismatch: bla.x # Uh oh, there we go!
> # Seems to have occurred while fetching r146971 (last passed rev + 1), so let's try it:
> svn log -v -r 146971 $svn
M /branches/y/bla.x
> # OK, bla.x is a good indicator that this is indeed our failing commit.
> # What was the preceding commit on it, according to SVN?
> svn log -v -r 146971 $svn/branches/y/bla.x | less
------------------------------------------------------------------------
r146971
  M /branches/y/bla.x
Modified bla.x
------------------------------------------------------------------------
r145665
  A /branches/y (from /branches/z:145664)
Rebasing y on z
------------------------------------------------------------------------
> # Exactly what we were looking for: a branch creation. Let us clean branch y
> # so that git-svn is forced to find its recreation commit:
> rm -R .git/refs/remotes/origin/y .git/*/refs/remotes/origin/y
> vi .git/info/refs .git/packed-refs # remove references to y
> git svn reset -r145665 -p
> git svn fetch

I'm supposing that git-svn did not see or apply the branch deletion, thought it was unnecessary to recreate it from branch z, and thus tried to applied 146971 on the old tree. Telling it there is no branch y forces it to play the branch creation (from z).

(1) mimicking in svn the equivalent of a git rebase z of branch y: svn mv y y.old && svn cp z y && svn merges to get all commits of y.old on the new y