Subgit：避免将git分支同步到svn上

Question

I am trying to use SubGit but I am facing a problem with branches: I would like branches created under Git to live and die inside Git only. I found this: SubGit: How to exclude branches? , but it says

The troubles come from merge commits: if commit A is the result of merging branch foo into master, then SubGit creates branches/foo on Subversion side for corresponding parent of commit A. . If you'd prefer to not include SubGit generated branches into branches/* namespace, consider using some special branches on Subversion side as well

I don't want to mess with the SVN because I am evaluating Subgit and I don't want to change anything on SVN. I guess I could my goal (meaning, committing to SVN only the merged history and not also the git branch) by rebasing before pushing to the Git repository, but I am afraid this could lead to conflicts when committing back to SVN. Any idea on how I can workaround this, without waiting for SubGit version 2.1 (claimed to do what I want but not in a near future - cit from linked answer: it's going to take some time before we implement it )?

Answer 1

SubGit synchronizes only branches you've specified in the SubGit config file. By default they are:

    trunk = trunk:refs/heads/master
    branches = branches/*:refs/heads/*
    shelves = shelves/*:refs/shelves/*
    tags = tags/*:refs/tags/*

So if you use another namespace, eg refs/heads/nosync/*, branches in it won't be synchronized.

Or you can use refs/heads/* for normal branches (that are out of synchronization) and setup special refs/heads/sync/* namespace for synchronization:

    trunk = trunk:refs/heads/sync/master
    branches = branches/*:refs/heads/sync/*
    shelves = shelves/*:refs/shelves/*
    tags = tags/*:refs/tags/sync/*

Note, that long branch names (like refs/heads/sync/master) don't lead to inconvenience because after cloning such Git repository, you can assign your own local refs/heads/* branches with short names to track branches with long names from one or another namespace. That's why I think this is a good solution for you.