A git mirror for Gnucash's Subversion Repository

[John Ralls]

On Feb 16, 2011, at 11:57 PM, Christian Stimming wrote:

> Dear John and all,
> 
> thanks a lot for setting this up! It is indeed interesting to see the latest SVN commits show up as cloned git commits rather soon by your cron job. https://github.com/Gnucash/gnucash/commits/master
> 
> As discussed before, I'm very much interested to play around with this new possibilities and see how git can indeed make our workflow easier (e.g.  forking on github etc). One fun feature of github are the comments on each commit, including comments on particular source code lines:
> 
>  https://github.com/Gnucash/gnucash/commit/91dc3f05bf16d0f352498289038191a5143daf13#configure.ac-P20
> 
> Zitat von John Ralls <jralls at ceridwen.us>:
>> What I found [1][2] ...
> 
> Errr, I didn't see the URLs to those references in your message...
> 
>> public repository -- but must never push to it. If he has svn commit privilege, he can also configure the git-svn information into his repo so that he can dcommit back into subversion. Those subversion changes will be eventually be reflected in the public git repo, and git-svn is smart enough to recognize the commit when it comes back around.
> 
> This is very much the workflow as described on http://stackoverflow.com/questions/1880405/can-different-git-svn-clones-of-the-same-svn-repository-expect-to-be-able-to-shar/3422422#3422422 and the reference to http://blog.tfnico.com/2010/08/example-git-svn-mirror-workflow.html : As a developer with write access, I will continue to use git-svn locally, but with the shared public git repo in between and also running the command
> 
>  git update-ref refs/remotes/git-svn refs/remotes/origin/master
> 
> each time after I've pulled from our shared git repo. Sounds doable.
> 
>> Developers without svn commit privs will have to send a pull request to someone who does. Github provides an easy mechanism for generating pull requests from one's own Github repo. Github also makes collaboration on feature branches easy -- they just have to be in your own Github Gnucash repo, not in the "official" one that mirrors subversion.
> 
> I expect a large benefit here because recently I've been doing a lot of patch committing, and it is cumbersome to figure out the correct -p argument which is different in each patch, and also setting up a suitable commit message. I expect if people send me a pull request I know I can already get their patches by the simple "git pull", not having to deal with patch formats or commit messages anymore. At least this part is surely an improvement for our (and particularly my) workflow.


Yes, it's the same workflow -- those URLs point to different places in the same author's blog (and the stack overflow page has an answer from that same author).

Today I got the Loeliger book that Yawar cited. It does indeed have a different approach, and if it works it will be more attractive because it allows the git users to do git-ish things (almost) as much as they like. The penalty is that only one repository is allowed to commit back to subversion. 

1. Create a git-svn repository as usual, passing a --prefix=svn/ arg to git svn clone. (Nicolaison doesn't use a prefix)
2. In a separate directory, create a bare git repo ("public") and git push -all from the svn repo to the new bare one, mapping refs/remotes/svn/* in the git-svn repo to refs/heads/svn/* in the new, bare, one. (Again, same for Nicolaison but without the  svn/ prefix.) Master is created as a tracking branch of svn/trunk, and any active svn branches (think 2.4) will similarly need tracking branches.

The public repository gets pushed to github and is periodically pulled back for synchronizing with subversion. Here's where things get interesting. To sync back into svn trunk (procedure would be the same for any subversion branch):

1. In the git svn repo, checkout master and pull from the public repo.
2. git checkout svn/trunk (This is in refs/remotes, so you get a detached head.)
3. git merge --no-ff master (Creates a merge commit rather than splicing the commits. This loses some history in svn, but so it goes.)
4. git svn dcommit pushes the commit into subversion.

I've left out a bit of detail in the checkout and had to interpolate some in for committing, so I'll have to test this out to make sure I have all of the details right and that it actually works... but that's also true of Nicolaison's method. Also, they're both silent on tags, and we need to integrate our tags so that we know where releases occurred.

(Status: I have the perl version of svn2git written and the first run didn't quite work; I think I mis-copied a command option. By the time I got that done, it was dinner time, so I'll have another go tomorrow morning.)

Regards,
John Ralls