JPz'log Coin Coin and Plop da Plop

On Git-SVN interoperability

This is a short entry to warn you on the Git / Subversion interoperability which I have advocated for quite some time now.

git-svn is a powerful Subversion client. Using it is a very good idea as long as:

1. you keep linear history on your branches thanks to rebasing (if you mess up with real merges you can still recover using squashed commits), and
2. you do not try to collaborate through Git with other folks too much (i.e., they need to fork your very own repository, and keep history linear as well).

There are some drawbacks when you collaborate with others through Git. An obvious one is that commits back to Subversion rewrite your Git history, which is never good for people who forked your branches.

However, the worst issue is that cloning a Subversion repository in Git yields different hashes over different runs... which means that although the trees and files in several svn-based clones of one repository are the same, they have different hashes, which means repositories with logically independent histories.

This does not mean that Git is wrong, or that the Git / SVN interoperability is flawed, but you must be aware of those issues.

PS: if you have an idea of why cloning Subversion repositories gives different hashes then I look forward to reading your comment!