Git SVN Advanced Configuration and Limitations

only one asterisk is allowed per word. For example: branches = branches/re*se:refs/remotes/project-a/branches/* will match branches 'release', 'rese', 're123se', however branches = branches/re*s*e:refs/remotes/project-a/branches/* will produce an error. It is also possible to fetch a subset of branches or tags by using a comma-separated list of names within braces. For example: ------------------------------------------------------------------------ [svn-remote "huge-project"] url = http://server.org/svn fetch = trunk/src:refs/remotes/trunk branches = branches/{red,green}/src:refs/remotes/project-a/branches/* tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/* ------------------------------------------------------------------------ Multiple fetch, branches, and tags keys are supported: ------------------------------------------------------------------------ [svn-remote "messy-repo"] url = http://server.org/svn fetch = trunk/project-a:refs/remotes/project-a/trunk fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo branches = branches/server/*:refs/remotes/project-a/branches/* branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/* tags = tags/server/*:refs/remotes/project-a/tags/* ------------------------------------------------------------------------ Creating a branch in such a configuration requires disambiguating which location to use using the -d or --destination flag: ------------------------------------------------------------------------ $ git svn branch -d branches/server release-2-3-0 ------------------------------------------------------------------------ Note that git-svn keeps track of the highest revision in which a branch or tag has appeared. If the subset of branches or tags is changed after fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove (or reset) branches-maxRev and/or tags-maxRev as appropriate. FILES ----- $GIT_DIR/svn/\**/.rev_map.*:: Mapping between Subversion revision numbers and Git commit names. In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the 'svn.noMetadata' section above for details). + 'git svn fetch' and 'git svn rebase' automatically update the rev_map if it is missing or not up to date. 'git svn reset' automatically rewinds it. BUGS ---- We ignore all SVN properties except svn:executable. Any unhandled properties are logged to $GIT_DIR/svn/<refname>/unhandled.log Renamed and copied directories are not detected by Git and hence not tracked when committing to SVN. I do not plan on adding support for this as it's quite difficult and time-consuming to get working for all the possible corner cases (Git doesn't do it, either). Committing renamed and copied files is fully supported if they're similar enough for Git to detect them. In SVN, it is possible (though discouraged) to commit changes to a tag (because a tag is just a directory copy, thus technically the same as a branch). When cloning an SVN repository, 'git svn' cannot know if such a commit to a tag will happen in the future. Thus it acts conservatively and imports all SVN tags as branches, prefixing the tag name with 'tags/'. SEE ALSO -------- linkgit:git-rebase[1] GIT --- Part of the linkgit:git[1] suite

This section discusses advanced configuration options for git-svn, including the use of comma-separated lists and braces to specify branches and tags, as well as limitations and potential issues with the tool, such as the handling of renamed and copied directories, SVN properties, and the importing of SVN tags as branches.