Yann Dirson venit, vidit, dixit 11.05.2009 13:08: > The following happens with git 1.6.3. For some reason git-svn sets HEAD > to the wrong branch. Not sure what happens here, $self->full_url seems to > be used for a wrong purpose somewhere in the code. > > > (you can see a commit on the "tag" branch, which got committed at the > wrong place because the user did not notice that HEAD was not pointing to > the correct branch) > > $ git svn clone --stdlayout svn://xxxx/at-remote test > [....] > Successfully followed parent > r3287 = 08b210cf2e97caeb6d431a4a0bc594702aa9c6d2 (tags/luciole-2.0.4) > Found possible branch point: svn://xxxx/at-remote/trunk => > svn://xxxx/at-remote/tags/luciole-2.0.5, 3352 > Found branch parent: (tags/luciole-2.0.5) > ddff7cedbd1d66c836153606db1f80ad3ce6b00d > Following parent with do_switch > Successfully followed parent > r3367 = 35b21f3f8e206c391f09a788ba9cb6b35f21752d (tags/luciole-2.0.5) > M at-remote > r3652 = faeb3bab02016b23a7fb7256bbabea305f599022 (tags/luciole-2.0.5) > Checked out HEAD: > svn://xxxx/at-remote/tags/luciole-2.0.5 r3652 > $ > > svn allows you to commit to tags as if they were branches - indeed they are branches just as much as svn branches are branches. Therefore, git-svn represents svn tags as git remote branches (not tags). After the clone is done, git-svn checks out the branch on which the last commit was done. So, git-svn is doing as it should, under the restrictions that svn puts on its operations. One may argue that master should point to trunk (for --stdlayout) instead after git svn clone, just like master points to master after git clone. But which one is "the correct branch"? I would claim that the client cannot know and there should be no master (maybe a detached head with the last commit, i.e. HEAD) but last I tried I remained a 1-person-minority ;) Cheers, 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