Hiya, The subversion repository I need to work with is quite odd (by my standards, anyways). The structure looks something like: |-- patches | `-- foobar | `-- project-name `-- trunk-team-name `-- project-name That is, a single monolithic repository. Each team has their own trunk (as a folder). The patches folder is essentially a production branch for a specific region. Each developer tends to have a branch somewhere else which they use to hack on. When they are ready, the code goes through a review process and then is copied (svn copy) into trunk. It then goes through a build process and is finally merged (in this case, using meld) into the patches where other stuff happens to it. I would like to use a single git repository for each project. That is, my master branch should relate to the project folder in trunk and my production-foobar branch should relate to the project folder in patches. I could then use git to hack on a local branch and merge to master (and then dcommit back to trunk). When ready, I could then merge master into the production branch (and then dcommit back to patches). I guess what I'm looking for is something like: git svn clone https://svn/url -T trunk-team-name/project-name -b patches/foobar/project-name However, I'm pretty sure that is wrong. Not only does it take forever (I landed up canceling it), but I don't think the git-svn branches will understand the weirdo layout. I tried manually adding svn-remotes, running git-svn fetch against then and then branching off. However, I started seeing weird things happening when merging (sometimes git-svn became attached to the wrong remote, sometimes it wouldn't update properly, lots of obscure merge conflicts..). In the worst case, I could clone each project (that is, trunk and patches) separately and manually merge. But if I can get git to do this for me, it'd make a lot of sense. If anybody has any ideas, I'd be extremely grateful. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html