A problem you will have is that git svn rebase actually rewrites the commit history of the git repository. This will cause conflicts with anyone pulling from that repo. The best solution is for everyone to git svn the svn repository on their own.
If you want to setup a remote repo so you can share branches, then everyone will just have to be aware that if the remote git branch is rebased to svn, they will have to force apply the new revision history to their local git repos.
Others can force their local repos to match the remote by using git pull --force. Though be warned, because that will invalidate any commits made after the alteration point. Example, say we have the following commit structure:
D----E topic
/
A----B----C----F master
Then we use git pull --force to update our local repository, which then changes the sha1 of the commits starting at B. Our new structure will look like the following:
D----E topic
A----G----H----I master
Notice how commits D and E are now floating in wonder land? That's because the branch point now no longer matches up with what was B, but is now G.
To get around this problem you need to make sure that your local branch point originates from a commit that won't be altered by running git svn rebase. After force pulling the remote you can then git rebase your local branch onto update remote branch.
Say we make the mistake of creating a branch from a commit point that will result in the floating wonderland described above. Well, then you'll have to wave the git wonder wand before you initiate a git pull --force. Like so:
Oops. B is going to be overwritten in the pull.
D----E topic
/
A----B----C----F master
Well, then we just need to git rebase A topic our changes on a commit that won't be altered.
D'---E' topic
/
A----B----C----F master
Then once the changes have come in, we can git rebase G topic and get our changes back to where we know they go.
D'---E' topic
/
A----G----H----I master
Hopefully this explains the pain of trying to run a central access git repo along side a svn repo.
