31

When I did a git svn rebase it stopped at one point saying:

Index mismatch: SHA key of a tree != SHA key of another tree. (I come to know that these SHA keys corresponds to a tree and not a commit from git show of the above two sha keys.)

re-reading <sha index of a commit in svn/trunk>
... list of files ...
fatal: bad object <SHA1 index of the bad object>
rev-list -1 <SHA1 index of the bad object> --not <SHA1 index of the revision it was trying to re-read>: command returned error: 128

I am not very experienced in the internal workings of git, so is there a sequence of steps to follow to dissect problems like these and possibly resolve them?

Matt Hulse
  • 5,496
  • 4
  • 29
  • 37
yasouser
  • 5,113
  • 2
  • 27
  • 41
  • 3
    The first think I would try with a suspected corrupted repository is a [`git fsck`](http://www.kernel.org/pub/software/scm/git/docs/git-fsck.html). – Greg Hewgill Nov 01 '10 at 23:33
  • @Greg-Hewgill: Thanks for your suggestion. I did a git fsck and it listed a bunch of dangling trees, commits and blobs. I am refering to this section in Git user manual: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-from-repository-corruption and try to figure out what happened in the repo. Fortunately, couple of weeks back I archived my .git folder for my colleague to get up and running with the repo. I used that and created a new repo and continuing with my work while I figure out what happened to the corrupted one. – yasouser Nov 03 '10 at 03:26
  • Only thing that I can think of is that someone else possibly rebased before you did, thus changing the SHA key of the remote repo and giving you the error you see now. If you were to pull the changes made to the tree, fix any conflicts, then rebase from there, it might work properly. – g19fanatic Nov 04 '10 at 13:27
  • You only saw dangling commits, no missing ones? This is reasonably normal -- dangling commits are created when rebasing and dangling trees when using `git add` -- the index is maintained as a tree. – Andrew Aylett Nov 04 '10 at 19:35
  • @g19fanatic The remote repository is an SVN repository, and SVN doesn't support history rewriting, so I'm not sure what you mean – Max Nanasy Aug 01 '13 at 18:15

10 Answers10

39

Please don't remove the .git/svn folder to fix this. It requires you to rebuild everything, it is annoying, it will take awhile (for the size of my repo several hours) and it is NOT NECESSARY.

I found the right answer here and I've included it below.

From the link:

Inside the .git directory run the following:

$ find . -exec grep -Hin 5b32d4ac2e03a566830f30a702523c68dbdf715b {} \;
Binary file ./svn/.caches/lookup_svn_merge.db matches
Binary file ./svn/.caches/check_cherry_pick.db matches

Now delete the matching .svn/.caches from the output of the first command

$ rm ./svn/.caches/lookup_svn_merge.db
$ rm ./svn/.caches/check_cherry_pick.db

Now git svn rebase or git svn fetch to your heart's content.

Matt Hulse
  • 5,496
  • 4
  • 29
  • 37
  • 2
    Yes I did find this technique later. During my next attempt I just cleared the `caches` and it was lot quicker than deleting the `.git/svn`. Forgot to update here. Thanks for posting your answer. – yasouser Jan 10 '13 at 18:46
  • I also had checksum mismatch at the same time in the message and this solution did not fix the problem in such case. – Sergei Krivonos Aug 15 '19 at 08:28
38

I've had this error twice and both times resolved it by removing the svn folder inside the .git folder.

rm -r .git/svn

then rebuild the svn metadata with:

git svn fetch

You will probably see a message along the lines of:

Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
    .git/svn
    (required for this version (1.7.0.4) of git-svn) does not exist.
Done migrating from a git-svn v1 layout

and after while (rebuilding can take a while especially on large repositories) you should end up with a working mirror of the svn repository again.

Matthew Buckett
  • 4,073
  • 1
  • 36
  • 28
  • 1
    +1 for simplicity; it's really overkill for large repositories but in most cases an overall time saver. – sam hocevar Mar 07 '11 at 17:26
  • Accepting this as the answer because, one of my colleague ran into the same problem (git index mismatch) today and we were able to recover the repo using the method suggested here. Since the repo is very huge it is taking quite while though. – yasouser May 05 '11 at 19:24
  • Took several hours to rebuild svn index data for my 1.2 GB repo, but it fixed the problem. – Tim Keating Nov 25 '11 at 01:43
  • 2
    For my large repository I fetched just some latest commits: "git svn fetch -r 12345:HEAD". I can still see previous commits. – Erdem May 04 '12 at 10:27
  • 1
    Definitely overkill and completely unnecessary. – Matt Hulse Jan 10 '13 at 17:42
  • 1
    This should come with a warning at a minimum. – deuberger Oct 18 '16 at 18:19
  • In my case runnning "git svn fetch" gives me, after "Done migrating from a git-svn v1 layout" one additional line: "open: No such file or directory at C:\brl\app\Git\mingw64/libexec/git-core\git-svn line 574." And If I understand my mirror is still KO – user1767316 Mar 08 '18 at 11:15
  • 1
    Adding `--log-window-size=5000` (or larger) will speed up the fetch greatly. – Ian Dunn Mar 22 '19 at 21:34
  • Took several hours to refetch svn data, but it does not fix the problem. – Sergei Krivonos Aug 15 '19 at 08:27
13

Update git client and refetch last svn commits using:

git svn reset -r 12345
git svn rebase

where 12345 is existing svn revision.

yarolig
  • 305
  • 3
  • 5
4

In my case, the issue was caused by a new/unknown svn author who was not in my authors file that git-svn was configured to use. It reported it in the output that that I ignored the first few reads:

Index mismatch: <leftsha1> != <rightsha1>
rereading <anothersha1>
        ... list of files ...
Author: <name> not defined in /path/to/authors file

So that gave me the name that I was missing, and what file to add it too (I pulled the email from my organizations user registry) and was smooth sailing.

ThorSummoner
  • 16,657
  • 15
  • 135
  • 147
1

The problem there is that you have to do this systematically in this case :

  • use git + svn
  • create branch on svn with git-svn
  • merge branch to trunk with svn tools
  • remove the svn branch
  • do a git-svn rebase

Something missing, everything crash. The only way I know to recover is do remove all svn in .git and rebuild everything. It's just annoying and take a while !

geistteufel
  • 19
  • 1
1

Likely, you may also have Checksum mismatch at the same time in your message:

I found solution here Git svn rebase : checksum mismatch:

git svn log <item with checksum mismatch>
git svn reset -r<top history revision in the log> -p
git svn rebase
Sergei Krivonos
  • 4,217
  • 3
  • 39
  • 54
0

I just had this error myself. Just delete the ref, like so:

rm .git/refs/remotes/git-svn

That should clear up the error.

Nzbuu
  • 5,241
  • 1
  • 29
  • 51
Michael Melanson
  • 1,325
  • 10
  • 21
0

Maybe something to do with Copy-On-Write feature of your filesystem (ext4/btrfs/etc...) ?

See : https://stackoverflow.com/a/42299634/7491491

Community
  • 1
  • 1
Raphaël G.
  • 19
  • 1
  • 5
0

I got this error:

Index mismatch: <sha> != <sha> re-reading <sha index of a commit in svn/trunk> ... list of files ... <path> was not found in commit <sha> (r<svn rev>)

Looking in SVN repo at the history of the reported path, I found the SVN revision where the file had been added. But looking in Git at the commit created for that revision I found that it didn't contain any files!

I think this had been caused by a full disk earlier. After doing a git svn reset -r back to the revision of the broken Git commit, git svn fetch worked fine again.

oliver
  • 6,204
  • 9
  • 46
  • 50
0

I ran into this during the initial cloning turns out someone created a branch called trunk which conflicted with the real trunk. After ignoring /branches/trunk all worked

David van Laatum
  • 634
  • 4
  • 13