Git tips for SVN users

November 19, 2009 – 7:27 pm Tags: ,

SVN is the version control system I’ve used the most, but lately I’ve been using Git more and more. I’ve also been using Git with projects that have an svn repository thanks to git’s built in svn support.

While working with it, I’ve ran into several typical cases that I’ve often needed to deal with, that I haven’t encountered with SVN, so I thought I’d share some tips with you, as I’m really starting to think Git is a much better tool than SVN.

Issues after starting

Getting branches

When I first cloned an svn repository using Git, I simply issued a git svn clone command. This clones the trunk of the SVN repository, but none of the branches.

Obviously I wanted to have the branches too. To get branches, tags and everything, you can issue the command like this:

git svn clone url/to/repo -T trunk -b branches -t tags

Warning: This can be very very… very slow if you have a large repository.

Refspec glob conflicts

This was a weird message I kept getting during svn rebases and commits. It turns out that Git had somehow mangled its own configuration file, putting the trunk, tags and branches multiple times into it.

You can fix this problem by going to the root of your repository, and into the .git dir. There should be a file called config, which contains a list of URLs to trunk, branches and tags. In my case, they were simply repeated multiple times, and removing the duplicates fixed the Refspec glob conflict error messages for good.


Constantly asking for your repository password

When you use Git with svn+ssh repositories, Git keeps asking for your password. This is especially a problem on Windows, as Git’s svn over http support doesn’t seem to work there at all.

You can fix this, but it requires you have some kind of access to the server with the repository – you need to be able to save your ssh public key there.

You first need to generate a key pair. A good guide for that can be found here. Then, you need to set up ssh-agent – a good guide can be found here

Merges with git branches

Don’t do it.

Merging your svn branches with other Git branches is an easy way to mess up your repository and as such you probably should avoid it. cherry-pick and rebase both cause a linear history, and those two can be used (with caution)

Other tricks

Partial commits

You can easily craft commits using git gui. It even lets you choose specific lines to commit, which is useful if you need to split the work you did into more than one commit. You can also use git commit -i to do something similar on the command line.

Saving work in progress

There are two typical methods you can use to save work in progress that you haven’t finished yet.

  • git stash: You can stash your changes for later applying it back.
  • git commit: You can simply commit your WIP-code.

At first I tended to use git stash – I found having commits that say “WIP”, “foo”, or whatever, weren’t particularily nice.

However, I think using an actual commit is a better approach, because then you usually have a message and a branch. With stash, I often found myself having some stashed code and I had no idea where it belonged. And with git rebase, you can rewrite the history to get rid of those incomplete work in progress commits.

Stash does have its uses though: I do find it convenient if I just want to momentarily put the changes away, but not for a very long period (ie. if I’m leaving stuff over the night, I do a commit instead)

Rewriting history

I’ve found that modifying one of my old commits is sometimes useful. For example, because I have a local Git repository, I can commit much more often than I’d commit with SVN. Some even suggest committing after every line, but I think that’s a bit overkill.

git rebase -i, the interactive rebase command which can be used for messing with your old commits, is a very powerful tool. You should be careful with it, as it’s possible to accidentally remove a commit. (It can be retrieved with git reflog so it’s not totally lost, but be careful anyway). You should also be careful to not touch any commits you have already shared with others – be it with git svn dcommit or pushing/pulling.

The simplest usage of rebase is to squash commits. Squashing a commit means it’s merged into the commit before it. This is very convenient if you have multiple work in progress commits, which you can then merge into one. Squashing guide at Git Ready

You can also go back and edit an older commit. This is convenient if you discover you had a bug which you’d rather fix in the same commit where you introduce the feature, or perhaps you want to add better comments to your code. It’s also possible to reorder the commits with rebase.

For more rebase tips, be sure to read my post on Git interactive rebase tips.

What is your favorite trick?

Share it in the comments!

Share this:

RSS feed Subscribe to my RSS feed

About the author

Jani is a 15 year veteran of the software industry. He's currently available for consulting

  1. 8 Responses to “Git tips for SVN users”

  2. Thanks. I’m on the lookout for tips/links for making the svn to git transition. I’m taking a new job soon in an org not currently using any SC, and I’m hoping to get the team on git from the get-go.

    By Steve Clay on Nov 20, 2009

  3. Posted on the DZone.

    By CodeJustin on Nov 24, 2009

  4. Git certainly does change the way you work.
    In a largish project that has many people committing, could result in broken builds and people waiting to commit their work resulting in delays, frustrations, merge hells, world war and what not.

    I use git-svn at work. But I have more than once broken the build while doing a git svn dcommit. What happened is that I would have had a few logical commits on git. By the time I push these changes to subversion I would get a conflict on one of the commits. So a few commits go through and a few don’t. And ofcourse this results in a really badly broken build. Ofcourse most of the time fixing this would be pretty easy , as you have resolve conflicts and dcommit again. But yes does raise your blood pressure as you would be holding up people from checking in their work.

    By c0dep0et on Nov 26, 2009

  5. Interesting – I haven’t ran into that yet. Thanks for pointing it out, good to know there may be issues like that.

    In the meantime, I guess it would be a good idea to always git svn rebase before committing.

    By Jani Hartikainen on Nov 26, 2009

  6. Thanks for the useful tip on fixing the “Refspec glob conflicts” errors.

    In my case I suspect the problem was caused by my initial “git svn clone” failing part-way, and then needing to be repeated.

    By Alex Peters on Dec 9, 2011

  1. 3 Trackback(s)

  2. Nov 28, 2009: 網站製作學習誌 » [Web] 連結分享
  3. Dec 7, 2009: Should I try Git if Svn/CVS/other works for me? | CodeUtopia - The blog of Jani Hartikainen
  4. Dec 10, 2009: Git interactive rebase tips | CodeUtopia - The blog of Jani Hartikainen

Post a Comment

You can use some HTML (a, em, strong, etc.). If you want to post code, use <pre lang="PHP">code here</pre> (you can replace PHP with the language you are posting)