Issue running git-svn-mirror script on code

Geert Janssens janssens-geert at telenet.be
Tue Jan 22 10:04:01 EST 2013


On 22-01-13 15:51, John Ralls wrote:
> On Jan 22, 2013, at 5:30 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>
>> Geert Janssens <janssens-geert at telenet.be> writes:
>>
>>> Another option would be to keep John's Jeeves set up to handle all
>>> git-svn interaction until we can drop our svn set up completely.
>>>
>>> The only change needed on John's server would be that it should push
>>> all updates to the gitolite repositories instead of the github
>>> ones. The gitolite manages repos then push to github.
>>>
>>> The last part is the only part we want to keep long term: master
>>> repositories in gitolite on code.gnucash.org, which sync to github for
>>> a wider audience.
>>>
>>> In the worst case, we have to keep the git-svn stuff around until we
>>> abandon the 2.4 development. But with some tweaking, it may even be
>>> dropped sooner.
>>>
>>> So the question is: is it worth the effort to try and replicate the
>>> git-svn bridge on code.gnucash.org ?
>> Maybe..  Here's the bigger issue, if I found issues/bugs in John's
>> svn->git conversion, what do we do?  (and yes, I found a problem in the
>> conversion)
>>
>> Let me back up.  I worked with john on IRC yesterday and tracked down
>> one issue:  I was using the wrong URL.  Apparently I need to use the
>> same URL he does, which means I cannot use the file:/// url, but instead
>> I had to use the svn+ssh:// url.  Moreover, I had to use
>> svn.gnucash.org, not code.gnucash.org, so there were two issues right
>> there.  But that wasn't sufficient.
>>
>> At this point it got late but I did one more test to compare the hashes
>> I was generating versus the hashes in the github repo.  Surprisingly,
>> running "git log | tail" the hashes at the end line up the same!!  So I
>> did some more research to figure out where the hashes diverge, and
>> *this* is where I found the bug in the current, existing conversion.  In
>> my version (using the current gnc-authors file) I see:
>>
>> -----
>> commit 647db0ea2b6dddb4c3239a073651250eb6f93fd4
>> Author: Joshua Sled <jsled at asynchronous.org>
>> Date:   Fri Mar 3 23:40:43 2006 +0000
>>
>>     remove old .cvsignore files.
>>
>>     git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk@13455 57a11ea4
>> -9604-0410-9ed3-97b8803252fd
>>
>> commit 6b119ea2b758d92a902d4de624f6b3637528e8c2
>> Author: Chris Shoemaker <c.shoemaker at cox.net>
>> Date:   Sun Feb 5 04:20:43 2006 +0000
>>
>>        Add a first-draft of a chapter on Budgets to the guide.
>>
>>
>>     git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk@13109 57a11ea4
>> -9604-0410-9ed3-97b8803252fd
>>
>> commit ef351012cde7c6757b29e9e26cf39e10c0e2fc7f
>> Author: Christian Stimming <stimming at tuhh.de>
>> Date:   Fri Nov 18 20:34:00 2005 +0000
>> -----
>>
>> But the github version of these same commits has:
>>
>> -----
>> commit 79363a72c3d9dbf2172cd21843417195cb2ee5b8
>> Author: Joshua Sled <jsled at asynchronous.org>
>> Date:   Fri Mar 3 23:40:43 2006 +0000
>>
>>     remove old .cvsignore files.
>>
>>     git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk@13455 57a11ea\
>> 4-9604-0410-9ed3-97b8803252fd
>>
>> commit 44c2d892a4a5d9735d1965f32de52e9a411615e8
>> Author: Christian Neumair <chris at gnome-de.org>
>> Date:   Sun Feb 5 04:20:43 2006 +0000
>>
>>        Add a first-draft of a chapter on Budgets to the guide.
>>
>>
>>     git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk@13109 57a11ea\
>> 4-9604-0410-9ed3-97b8803252fd
>>
>> commit ef351012cde7c6757b29e9e26cf39e10c0e2fc7f
>> Author: Christian Stimming <stimming at tuhh.de>
>> Date:   Fri Nov 18 20:34:00 2005 +0000
>> -----
>>
>> Notice that in *MY* version, the second commit is by "Chris Shoemaker
>> <c.shoemaker at cox.net>", whereas github has that commit by "Christian
>> Neumair <chris at gnome-de.org>".  This is why the hashes don't match.
>>
>> So, do we care about correctness of the git repository?  I don't know
>> how we recover from this dichotomy.  I don't know if github will let us
>> "reset" the repositories?  Of course it would mean that EVERYONE'S repo
>> will be broken...   :-/
>>
>> Personally, I feel that it's important to have the history "correct",
>> even if it means resetting and invalidating the existing repos.
> It's due to a change [1] Chris Shoemaker requested here a few months ago.
>
> Yes, this is a good opportunity to fix the history. We can simply delete and regenerate the Github repos. No problem, I had to do it a couple of times when I did the original conversion. Everyone will then have to re-clone and reattach any private branches. A PITA, but a one-time one.
What steps would your recommend to reattach private branches ? With my 
(limited) git knowledge I would only know how to export (git 
format-patch) from the old repo and import (git am) in the new clone. Is 
there a more direct way to do this ?

Geert


More information about the gnucash-devel mailing list