Coming clean, after being stupid and ugly (or: globs and filtering with git-svn)

Coming clean, after being stupid and ugly (or: globs and filtering with git-svn)

[Michael J Gruber]

Hi there,

I've been a sinner regarding good repo structures: I lumped a lot of 
stuff into one SVN repo. I blame SVN's clumsy admin commands and URLs 
for that, of course... Along with my transition to git I want to change 
this structure.

At the root of my SVN repo I have directories trunk/A, trunk/B and 
trunk/C, say; similarly for branches/*/A etc.

I know how to "git-svn clone -s" the tree under A so that it becomes an 
independent git repository (using "branches = 
branches/*/A:refs/remotes/*" etc., i.e: git-svn init, edit config, 
git-svn fetch).

But I want the trees under B and C to end up in the same git repository 
(under B and C, of course). I could convert the whole SVN repo and 
remove A afterwards using git-filter-branch, but this changes commit IDs 
and leaves spurious branches, tags and commits which touch the tree 
below A only, and would need to be removed also.

Is there any way to tell git-svn to do the filtering? It does some sort 
of filtering already (evaluating the fetch, branches and tags glob 
patterns). I would need something like

branches/*/{B,C}:refs/remotes/*

or

branches/*/{B,C}:refs/remotes/*/\1

to mean: treat only the trees below branches/something/B and 
branches/something/C and put them into subdirs B resp. C of the same git 
repo in branch something, for each something there is.

Alternatively: Where in git-svn should I look if I wanted to implement 
something like that?

Cheers,
Michael

P.S.: Actually, the tree below A will end up in a tree of smaller repos, 
and in my case I have more than just B and C which should end up in the 
same repo. The description above is a minimal case.