Q: workflows when tied back to git-svn

Hi list;

We have a number of projects which currently are mastered in a centralised svn repo, and it makes use of svn:externals. It's becoming increasingly apparent (finally) that everyone working in the various project /trunks is not working, and what's really required is a number of branches. Also that the git submodule approach is superior (for our needs) to svn:externals.

Now ideally, I could swap us all over to git; I've been using git-svn for a while and it works very nicely (modulo not noticing the requirement to merge with --squash, which is obvious once you know!). How-ev-er.. the natives are revolting.. some people didn't even want to move to SVN from CVS let alone a new tool. Alas some people just don't like change.

I'm guessing I can give teams their branches in svn, and manage the merging back with git and git-svn - that way I'll retain some kind of sanity in repeated merging. For those devs with the right fu can start using git directly, and we slowly start deprecating the whole svn infrastructure a bit at a time.

Anyone got any experiences of doing this (particularly things to note, like the --squash thing that might trip us up, or workflows)? I've never tried dcommitting back to anything other than trunk..

Secondly (slightly related) - because of our svn:externals usage, we
tend to have a lot of repeated repo checkouts. I'm *assuming* that If
I've got 2 git modules that have the same submodules (e.g
A
  mod1
  mod2

B
 mod1
 mod2

Then it's 'safe' to make the mod1 and mod2 directories symlinks to the same directory?