Sebastian Leske venit, vidit, dixit 23.11.2012 08:29: > Document that 'git svn' will import SVN tags as branches. > > Signed-off-by: Sebastian Leske <sebastian.leske@xxxxxxxxxxx> > --- > Documentation/git-svn.txt | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt > index 92780ef..6212b24 100644 > --- a/Documentation/git-svn.txt > +++ b/Documentation/git-svn.txt > @@ -938,6 +938,12 @@ 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/'. > + If git-svn turned SVN tags in git lightweight tags it would be just as conservative, because they can be rewritten also... It's just a ref. Note that the above assumes standard refspecs. But, importing SVN tags as branches conveys their character much more precisely. If r8 is being tagged then svn creates r9, which may or may not be treesame to r8; different projects do different things in this step. Even if they are treesame, r9 still carries a separate commit message. This is probably the most typical case, and converting the r9 commit into a git tag object would be appropriate (but is left to the user of git-svn). A lightweight tag pointing to an "off-branch" commit (r9) would be a strange thing, so git-svn creates a new branch instead, pointing at r9, branching off r8. > CONFIGURATION > ------------- > > -- 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