Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> wrote: > On Sat, Dec 08, 2007 at 06:26:24PM -0800, Eric Wong <normalperson@xxxxxxxx> wrote: > > I'm not sure if it's considered a "bug", but that's just the > > way it is at the moment. I can't remember why, but I did > > make git-svn force the presence of the "remotes/" prefix > > in all refs it writes to... > > okay, i see. one problem: git-svnimport is to be removed and (afaik) the > supposed way is to use git-svn instead. what is the supposed way to use > git-svn to convert an svn repo to a git one if the method i tried is not > working? > > (if the branches are fetched to "remotes/" then they won't be visible > when one clones the converted repo) I'm pretty sure the reasoning behind "remotes/" being forced by git-svn was to prevent users from shooting themselves in the foot, since committing to those remote refs will break both git-svn fetch and dcommit... Heck, the entire "remotes/" idea started because a git-svn user made the mistake of committing to the remote tracking branch directly: http://thread.gmane.org/gmane.comp.version-control.git/16869/focus=16875 I'll consider accepting a patch to lift that restriction (but still use the "remotes/" by default, of course). Also, it's possible to fetch them after editing .git/config a little: Harvey Harrison's "[RFC] Mirroring svn" post has a good example on how to do it. 1196922153.10408.101.camel@brick">http://mid.gmane.org/1196922153.10408.101.camel@brick Perhaps git-clone could gain the ability to clone refs/remotes/ as-is without an extra step? -- Eric Wong - 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
