Git Troubleshooting

I've had the fortune of being an early adopter for Git as a version control system. A part of this early adoption involves getting bleeding edge software to work alongside older, more decrepit software. Such was the case when using git as my subversion (svn) client.

During my trials with getting git to work as an SVN client (via the git-svn command) I've had to work around a few issues. Actually two issues. Exactly. Given that I've been doing this ~5 days/week for about two years, and given that git was never designed with this use-case in mind I find it absolutely amazing that this works so well. Two errors. Both of which have easily resolved solutions.

If only visual studio in Parallels worked this well. Anyway, today I will share these particularly pernicious errors, and the resulting solution for them.

Error type #1

After doing a git svn rebase, and getting some merge conflicts -- which were subsequently taken care of -- I decided to dcommit¹ my changes.

Usually, this pushes my changes from git to subversion, then rewrites git's history after the changes have been recorded on the svn server.

This time after dcomitting I recieved this error.

r86029 = e2df6bd331aed16979ead758633fbd76dbd1f8d3 (refs/remotes/trunk)
Checksum mismatch: src/Millstone.Web/Millstone.Web.csproj
expected: 001f2cb35417d18fe27c653a96a89d1f
    got: b9a26bb6ca0f2c3660976a551b9da525

This message basically states that the contents of Millstone.Web.csproj were not what was expected.

On my end this manifested itself as an inability to show the file Millstone.Web.csproj as a part of a commit that I expected to see it in.

The file did exist in the intended commit on the SVN server, so pushing up from git to svn worked fine. The problem then, was in puling the information back down from svn and recording it with git. Since it was the pulling the info back down that had problems I could, technically, just create a new checkout and all would be well. Fresh git checkouts can take a lot of time on large repos however -- which this was not, thankfully.

Though downloading a new copy of this repository would have been trivial, it's best to find a solution to these types of issues before working on big projects, when they becoming big problems.

The solution I found @ stack overflow and victoriakirst.com was to do the following:

• Do a git svn log on the file to find it's last svn revision.
• Reset git to one revision before the file's last svn revision.
• Do a git svn fetch to update git with information from the svn repo.

Here are the commands:

git svn log -n4 src/Millstone.Web/Millstone.Web.csproj

You'll notice I use the path returned in the 'Checksum mismatch: ' portion of the message above, and not the relative path to the file. i.e. not git svn log -n4 Millstone.Web.csproj which would give the error:

fatal: ambiguous argument 'Millstone.Web.csproj': unknown revision or path not in the working tree.

The output should look similar to

------------------------------------------------------------------------
r86026 | PROBABLE\xxx.xxx | 2014-07-16 15:54:06 -0400 (Wed, 16 Jul 2014) | 1 line

------------------------------------------------------------------------
r86022 | PROBABLE\yyy.yyy | 2014-07-16 14:36:07 -0400 (Wed, 16 Jul 2014) | 1 line

------------------------------------------------------------------------
r86018 | PROBABLE\aaaa.aaaa | 2014-07-16 12:22:29 -0400 (Wed, 16 Jul 2014) | 1 line

------------------------------------------------------------------------
r86012 | PROBABLE\bbbb.bbbb | 2014-07-16 11:03:37 -0400 (Wed, 16 Jul 2014) | 2 lines

To reset my local git repository I issued the following command: git svn reset r86012. The sharp reader will realize that this I went further than one revision down. Typos, gotta love 'em.

The git svn reset was followed next by: git svn fetch

Which gave me:

Index mismatch: 9c21630d2ac96f0e59b37776d5d12f6c82c7f7c7 != 19a1160f7664c5924b687b3516f2c5d5f694c58f
rereading 440f6c12b8159b51f0b3291c0fcbd6e989d5562d

After this I was back to the seeing the latest changes svn had recorded for my check in. I could now see Millstone.Web.csproj as a part of the commit which it should have been.

Mission accomplished.

Error type #2

Another error I happen to have come across is:

BigRedesign/branches/861203959-002_BRD_July_FY15/src/MaryWhite.Web/MaryWhite.Web.csproj was not found in commit 8e38cce0a559807b5c68dcc6a10cafbd8f356842 (r85468)

This is an error of the type <file> was not found in commit <hash> (<svn-revision>) According to the internets this seems to mean that git is being told about a file which has changed in SVN, BUT git has no record of the parent SVN commit in its repository history.

To deal with this I used git svn reset to roll back my local git repo to a commit before this conflict appears. Once I'm at the reset point, I perform a git svn rebase to pull in the new (modified history).

As you'll see the process for dealing with this type of change is similar to our problem above

git svn reset  r85458
r85458 = 388f4e6c99e98200e6f71d1bbba6526cf55f5442 (refs/remotes/861203959-002_BRD_July_FY15)

git svn rebase
Index mismatch: 351a62af11d5b83b2fb8054abc4c6d676ce518a1 != 4b825dc642cb6eb9a060e54bf8d69288fbee4904
rereading 388f4e6c99e98200e6f71d1bbba6526cf55f5442
Found possible branch point: https://xxxxx.xxxxx.xxxxx.com/content/Project/BigRedesign/trunk => https://xxxxx.xxxxx.xxxxx.com/content/Project/BigRedesign/branches/861203959-002_BRD_July_FY15, 85467
Found branch parent: (refs/remotes/861203959-002_BRD_July_FY15) 5837144ca00b23d87b08296a00a8a9f7855cf0e1
Index mismatch: 02cf8899a60db4aee8b00e4fb0d2ce5b9b84a0bc != 351a62af11d5b83b2fb8054abc4c6d676ce518a1
rereading 5837144ca00b23d87b08296a00a8a9f7855cf0e1
Following parent with do_switch
Successfully followed parent ...

git svn fetch
Found possible branch point: https://xxxxx.xxxxx.xxxxx.com/content/Project/BigRedesign/trunk => https://xxxxx.xxxxx.xxxxx.com/content/Project/BigRedesign/branches/3949-002_BRD_Aug_FY15, 86098
Found branch parent: (refs/remotes/3949-002_BRD_Aug_FY15) bdaff5444aa63227930af847f7885da62d1c266c
Following parent with do_switch
Successfully followed parent

Keep in mind, the way the git svn works is it:

• records git commits to a local repository
• pushes the locally recorded changes to a remote subversion instance.
• pulls that info back from subversion and then rewrites the local git history with whatever subversion returns to it.

I say this to point out that once your (or another individual's) commits are pushed to subversion, they wont be lost, so doing this reset is safe².

In my case, I only encountered this problem when using git svn fetch because I wanted to update the remote svn branches (since a few new ones were created since the last time I did an svn rebase).

---