That's ugly...

Chris Shoemaker is the name associated with svn name "chris", so the issue is indeed in the github repo.

I agree to restart from scratch on github. I also prefer correctness of authorship.

I have a couple of local branches with commits not on github, but that doesn't matter. They can easily be moved over to a fresh and fixed clone. I'd use git format-patch to export the branches into convenient patches, which are easy to import in the new repo using git-am. Would take only a couple of minutes in all.

On github, you can delete the repos we control, but the clones will not be dropped.

To be fair to the other clones, I think we should try to communicate as much as possible about the issue, the cause, how we intend to fix it, the impact it will have and how others can recover.

There are a couple of channels we can use:
- the main website
- the mailing lists
- the git wiki
- perhaps our facebook and google+ groups
- if possible some form of direct communication inside github to the other fork owners

Geert

On 22-01-13 14:30, Derek Atkins wrote:
Geert Janssens <janssens-ge...@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 <js...@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.shoema...@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 <stimm...@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 <js...@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 <ch...@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 <stimm...@tuhh.de>
Date:   Fri Nov 18 20:34:00 2005 +0000
-----

Notice that in *MY* version, the second commit is by "Chris Shoemaker
<c.shoema...@cox.net>", whereas github has that commit by "Christian
Neumair <ch...@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.

Geert
-derek


_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to