lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Converting a proprietary svn repository to git


From: Vadim Zeitlin
Subject: Re: [lmi] Converting a proprietary svn repository to git
Date: Mon, 29 Feb 2016 18:28:55 +0100

On Mon, 29 Feb 2016 16:58:42 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-02-26 02:01, Vadim Zeitlin wrote:
GC> [...]
GC> >  The next step would be to "git push --all" to some bare repository and
GC> > then clone it from somewhere else and verify that everything looks good.
GC> 
GC> Please help me understand an obstacle that I encountered when trying that.
GC> 
GC> For clarity and reproducibility, I've put the whole process in a script [0].
GC> It works correctly on GNU/Linux, but fails on Cygwin (versions below[1]).
GC> 
GC> On GNU/Linux, right after the 'git svn clone' step, branches are thus:
GC>   git branch -r
GC>     trunk
GC>   git branch -a
GC>   * master
GC>     remotes/trunk

 This is how older versions of git-svn did things and the way I'm familiar
with (because I stopped using svn before git-svn change was changed). I'll
freely admit that it doesn't make much sense however, "trunk" is a remote
branch, so it should be called "remotes/$svn_remote_name/trunk" normally...

GC> However, on Cygwin, at the same point branches are instead thus:
GC>   $git branch -r
GC>     origin/trunk
GC>   $git branch -a
GC>   * master
GC>     remotes/origin/trunk

 I.e. how the newer versions of git-svn work. I believe this has changed in
https://github.com/git/git/commit/fe191fcaa58cb785c804465a0da9bcba9fd9e822
i.e. around Git 2.0.0 release, which seems to fit the versions given. The
commit message also explains how to make the new version behave as the old
one: you need to give it --prefix "" to git svn init or clone. Whether it's
the right thing to do is another question, personally I agree with
everything the commit message says about how the old behaviour was wrong
and surprising.

GC> Then attempting to rename the 'trunk' branch fails:
GC>   git branch -m trunk master
GC> 
GC>   error: refname refs/heads/trunk not found

 That's because it really doesn't exist (you can look under .git/refs/heads
to confirm it), it is called origin/trunk.

GC> and cloning from the bare repository fails:
GC>   git clone file:///tmp/migration/temporary-bare
GC> 
GC>   Cloning into 'temporary-bare'...
GC> 
GC>   warning: remote HEAD refers to nonexistent ref, unable to checkout.

 This is a bit less clear, HEAD should point to master normally. What does
"git symbolic-ref HEAD" say?

GC> I think I've found the point where it fails, but why is 'origin/'
GC> prepended to 'trunk' on Cygwin, and what's the right way to fix it?

 The way to fix it is to use --prefix "" (I'm not sure if it's supported
by the old version however, it could be, but I didn't test it) but, again,
it might be better to just explicitly use something like --prefix=svn for
both the new and old versions and update the script accordingly. Another
possibility would be to just require Git 2.0 and always rely on the new,
more correct, behaviour, but this risks difficult as long as you stay on
Wheezy which has 1.7 and only has 1.9 in the backports repository (Jessie
has 2.1, by contrast). Of course, it's very simple to build Git yourself if
you'd like to, but it's probably not worth it just for this. OTOH I'd
strongly advise you to update to at least 1.9 from the backports as 1.7 is
almost 4 years old and there have been many, many nice improvements to Git
since then.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]