Sebastian Leske venit, vidit, dixit 18.11.2012 18:08: > git svn will sometimes create branches with an at-sign in the name > (branchname@revision). These branches confuse many users and it is a FAQ > why they are created. Document when git svn will create them. > > Signed-off-by: Sebastian Leske <sebastian.leske@xxxxxxxxxxx> > --- > > I found various important features of git-svn that are not documented. > Thus I created a series of patches to add and update documentation for > git-svn. I am sending this as four patches (of which this mail is the > first). I have tried my best to make the patches ready for inclusion > into git, but if there's any feedback, I'll gladly incorporate it. > > > Documentation/git-svn.txt | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt > index 8b0d3ad..482d60d 100644 > --- a/Documentation/git-svn.txt > +++ b/Documentation/git-svn.txt > @@ -881,6 +881,32 @@ different name spaces. For example: > branches = stable/*:refs/remotes/svn/stable/* > branches = debug/*:refs/remotes/svn/debug/* > > +If 'git svn' is configured to fetch branches (and --follow-branches > +is in effect), it will sometimes create multiple branches for one SVN > +branch, where the addtional branches have names of the form > +'branchname@nnn' (with nnn an SVN revision number). These additional > +branches are created if 'git svn' cannot find a parent commit for the > +first commit in the branch, to connect the branch to the history of the > +other branches. Normally, 'git svn' will find the git commit that > +corresponds to the SVN revision a branch was created (copied) from and > +use that as the parent. However, it is possible that there is no > +suitable git commit to serve as parent. This will happen, among other > +reasons, if the SVN branch is a copy of a revision that was not fetched > +by 'git svn' (e.g. because it is an old revision that was skipped with > +'--revision'), or if in SVN a directory was copied that is not tracked > +by 'git svn' (a branch that is not tracked at all, or a subdirectory of > +a tracked branch). In these cases, 'git svn' will still create a git > +branch, but the branch will not be connected to the history of the other > +branches. 'git svn' will also create a commit from the SVN revision the > +branch was copied from, and use that as the parent commit of the branch > +(this is indicated by the message "Initializing parent: <branchname>"). > +Additionally, it will create a special branch named > +'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision > +number the branch was copied from. This branch will point to the > +specially created parent commit. > +If in SVN the branch was deleted and later recreated from a different > +version, there will be multiple such branches with an '@'. > + > BUGS > ---- > > In fact, the most typical reason for at-branches is a botched branching or tagging operation on the svn side: since they are simply "copy" operations it's too easy to copy a tree into the wrong directory. Michael -- 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