Re: git-svn branch naming question

From: Eric Wong <normalperson@yhbt.net>
Date: Dec 9, 2007, 03:26 UTC
Message-ID: <20071209032608.GB31033@soma>
In-Reply-To: <20071209023600.GP3199@genesis.frugalware.org>

Miklos Vajna <vmiklos@frugalware.org> wrote:

Show 13 quoted lines

> On Sat, Dec 08, 2007 at 06:26:24PM -0800, Eric Wong <normalperson@yhbt.net> 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.

  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