Thread (13 messages) flat view 13 messages, 5 authors, 2016-06-15

Re: git-svn branch naming question

From: Eric Wong <hidden>
Date: 2016-06-15 22:43:57

Miklos Vajna [off-list ref] wrote:
On Sat, Dec 08, 2007 at 06:26:24PM -0800, Eric Wong [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help