tags:

views:

120

answers:

1

This wasn't so bad at the beginning, but now I have hundreds of no-op merge problems (solved by git rebase --skip).

I have setup a shared git repo for my group because it is easier to deal with. But the company uses SVN so I have to keep SVN in sync with GIT. Worked like a dream at first, but after weeks of doing this GIT is giving me a lot of the following errors.

Applying:  * making all config actions work
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging app/controllers/vulnerabilities_controller.rb
CONFLICT (content): Merge conflict in app/controllers/vulnerabilities_controller.rb
Auto-merging public/javascripts/network_analysis_vulnerability_config.js
CONFLICT (content): Merge conflict in public/javascripts/network_analysis_vulnerability_config.js
Failed to merge in the changes.
Patch failed at 0046  * making all config actions work

My workflow:

git co master
git pull origin
git svn rebase
... deal with no-op merge problems ...
git svn dcommit
git pull origin
git push origin

The problem is that what is in SVN is the correct so I use git rebase --skip, but I have to do that hundreds of times before I can dcommit.

How do I clear these merge problems permanently?

+2  A: 

I don't think this workflow is a good idea at all. Subversion only supports linear history so the branch you synchronize with SVN should not have any merge commits in it. Also, git svn dcommit rewrites the commits that are pushed (i.e their SHA changes), which can cause bad things to happen if they have been shared with another repo already. See the CAVEATS section of git help svn.

Maybe this kind of workflow could help: http://unethicalblogger.com/posts/2008/10/git_back_subversion_mostly_automagically_part_33

amx