Avoiding conflicts while using git-svn

Question

Folks I'm facing repeated code conflicts while pulling from the shared git repo in the following scenario:

1. There is a common svn repository

2. There are several developers who track/sync this common svn repo with their own local git repos using git-svn bridge(via git svn rebase/dcommit)

3. From time to time these developers using git need to share their changes without affecting the svn repository. For this purpose they setup a shared git repo and exchange their work using pull/push commands

4. It turns out these developers may face conflict problems due to usage of “git svn rebase” for syncing with the main svn repo. This happens because rebase operation rewrites history of the local git branch and it becomes impossible to push into the shared git repo and pulling from it often leads to conflicts.

Anybody having the same problem?

Answer 1

git-svn(1) says:

For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git-svn users clone, fetch and dcommit directly from the SVN server, and avoid all git-clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git-format-patch and git-am, or just 'dcommit'ing to the SVN repository.

If your situation allows it, you can use branches (i.e. subdirectories) in the SVN repository to isolate your work from the other developers.

Answer 2

What I found out is that merging git-svn changes to various git branches and between them is quite okay. The point where git-svn problems start is merging these changes back to svn (or rather, git branch from which you dcommit). It seems to me that most of these problem can be prevented if you merge your changes back to svn manually (e.g. by git diff | patch). This will strip history from thing you merge, but subversion users are used to this to it's not a big deal.