{"thread":{"id":"19288","subject":"Re: [BUG] git-svn: HEAD pointing to a tag after cloning","startedAt":"2009-05-11T14:09:42Z","lastAt":"2009-05-11T14:09:42Z","messageCount":1,"participants":["Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113540","messageId":"53308.10.0.0.1.1242050982.squirrel@intranet.linagora.com","threadId":"19288","inReplyTo":null,"subject":"Re: [BUG] git-svn: HEAD pointing to a tag after cloning","fromName":"Yann Dirson","fromEmail":"ydirson@linagora.com","sentAt":"2009-05-11T14:09:42Z","receivedAt":"2009-05-11T14:09:42Z","isPatch":false,"sender":{"key":"ydirson@linagora.com","avatar":null},"body":"> svn allows you to commit to tags as if they were branches - indeed they\n> are branches just as much as svn branches are branches.\n>\n> Therefore, git-svn represents svn tags as git remote branches (not\n> tags). After the clone is done, git-svn checks out the branch on which\n> the last commit was done.\n\nI am aware of that.  However, nothing seems to prevent svn tags to be\nmapped to tag refs insead of head refs.  Maybe both behaviours could be\navailable, if someone wants to be able to \"commit to svn tags\" properly\nfrom git, but since that is probably not the common case, I would rather\nsee this current behaviour as an option.\n\nBut we are going off-topic here.  That \"feature\" of git-svn checking out\n\"the branch on which the last commit was done\" is fortunately not being\ndocumented in the manpage :).  The problem here (distinct from the\ntag-handling issue) is that you can barely predict what svn remote your\nmaster branch will track !\n\n> One may argue that master should point to trunk (for --stdlayout)\n> instead after git svn clone, just like master points to master after git\n> clone.\n\nExactly, that would simply be consistent.\n"}]}