Git SVN Configuration and Best Practices

note the following rule: 'git svn dcommit' will attempt to commit on top of the SVN commit named in ------------------------------------------------------------------------ git log --grep=^git-svn-id: --first-parent -1 ------------------------------------------------------------------------ You 'must' therefore ensure that the most recent commit of the branch you want to dcommit to is the 'first' parent of the merge. Chaos will ensue otherwise, especially if the first parent is an older commit on the same SVN branch. 'git clone' does not clone branches under the refs/remotes/ hierarchy or any 'git svn' metadata, or config. So repositories created and managed with using 'git svn' should use 'rsync' for cloning, if cloning is to be done at all. Since 'dcommit' uses rebase internally, any Git branches you 'git push' to before 'dcommit' on will require forcing an overwrite of the existing ref on the remote repository. This is generally considered bad practice, see the linkgit:git-push[1] documentation for details. Do not use the --amend option of linkgit:git-commit[1] on a change you've already dcommitted. It is considered bad practice to --amend commits you've already pushed to a remote repository for other users, and dcommit with SVN is analogous to that. When cloning an SVN repository, if none of the options for describing the repository layout is used (--trunk, --tags, --branches, --stdlayout), 'git svn clone' will create a Git repository with completely linear history, where branches and tags appear as separate directories in the working copy. While this is the easiest way to get a copy of a complete repository, for projects with many branches it will lead to a working copy many times larger than just the trunk. Thus for projects using the standard directory structure (trunk/branches/tags), it is recommended to clone with option `--stdlayout`. If the project uses a non-standard structure, and/or if branches and tags are not required, it is easiest to only clone one directory (typically trunk), without giving any repository layout options. If the full history with branches and tags is required, the options `--trunk` / `--branches` / `--tags` must be used. When using multiple --branches or --tags, 'git svn' does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, use 'init' to set up your Git repository then, before your first 'fetch', edit the $GIT_DIR/config file so that the branches and tags are associated with different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* CONFIGURATION ------------- 'git svn' stores [svn-remote] configuration information in the repository $GIT_DIR/config file. It is similar the core Git [remote] sections except 'fetch' keys do not accept glob arguments; but they are instead handled by the 'branches' and 'tags' keys. Since some SVN repositories are oddly configured with multiple projects glob expansions such those listed below are allowed: ------------------------------------------------------------------------ [svn-remote "project-a"] url = http://server.org/svn fetch = trunk/project-a:refs/remotes/project-a/trunk branches = branches/*/project-a:refs/remotes/project-a/branches/* branches = branches/release_*:refs/remotes/project-a/branches/release_* branches = branches/re*se:refs/remotes/project-a/branches/* tags = tags/*/project-a:refs/remotes/project-a/tags/* ------------------------------------------------------------------------ Keep in mind that the `*` (asterisk) wildcard of the local

This section provides guidelines for working with git-svn, including rules for using 'dcommit', cloning repositories, and handling repository layouts, as well as configuration options for the $GIT_DIR/config file, such as setting up branches and tags with custom name spaces, and using wildcards to fetch specific paths from the SVN repository.