threads / discuss / 14098

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

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

## tl;dr

One message between Jun 23, 2008 and Jun 23, 2008.

replies: 0people: 1as markdown or json

Michael J Gruber· Jun 23, 2008, 13:17 UTC · lore
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.

← back to recent threads