On Thu, Apr 1, 2010 at 10:31 PM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote: > Given two separate git repositories initialized from the same > subversion repository, if the hashes are calculated from the data > alone, then those two repositories could theoretically pull/push > branches from each other while retaining the ability to commit back > to the "origin" subversion repository. > > If this is in fact the case, it would make it quite simple for me to > convince the more ambitious developers on our team to use git locally, > and grow team usage in a passive, viral way. This *almost* works. The problem is 'git svn dcommit'. It eats your git-created commits, and generates *new* ones by committing back to svn and then retrieving the newly-created commits. It's essentially the same as rebasing, which makes future git merges not really work. You can minimize the impact of this problem, however. The easiest way is: - have only a single person use git-svn - when committing stuff to git-svn, first checkout the *existing* git-svn branch, then use "git merge --no-ff mybranch", then "git svn dcommit". The --no-ff is very important; this makes sure that a *new* commit is created (a merge commit) for the svn dcommit. svn dcommit then creates only a single svn commit that includes all the patches from the whole branch. - then do 'git checkout mybranch; git merge git-svn' to get the svn commit back. At work, we have a cronjob that basically does most of these steps for us. Then there's a central git repo that corresponds to the svn repo; people who want to use git can use that repo and not worry about git-svn. Hope this helps. Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html