:-) That's alright. I finally got things working myself. Step one (assuming an existing repository cloned from buildr/buildr):
$ git remote add apache git://git.apache.org/buildr.git $ git fetch apache $ git branch trunk apache/trunk Step two: $ cd .git $ wget http://git.apache.org/authors.txt $ cd .. $ git config svn.authorsfile .git/authors.txt Step three: $ git checkout trunk $ git svn init --prefix=apache/ --username=djspiewak -s https://svn.apache.org/repos/asf/buildr $ git svn rebase At this point, you should have a fully-updated trunk/ branch in sync with the SVN repository. Now, the annoying part... For each local branch, we have to identify the exact branch-point; where that branch diverged from the SVN trunk/. Now, find the corresponding commit in the `trunk` branch and tag it as `branch-point`. Perform the following: $ git checkout *branch* $ git rebase branch-point # resolve any conflicts using mergetool If you do this for all your branches, you should get a working tree based on the new git clone. You can git svn dcommit from trunk/ and the results will be pushed into the SVN as expected. Running a git svn rebase in trunk/ will bring it up to date with any new changes. The main disadvantage to this rebasing is that you will lose any merge history between your local branches. All of the commit data should still be there, but rebase will linearize it for each branch you rebase. In other words, if you started with four local branches with various cross-merging, you will end up with four local branches without any connectivity whatsoever. I think it's a small price to pay though for actually getting this working. Are we planning to re-sync the "townhall" based on the official Apache clone? I would vote "no" on this one, instead pointing Git-hungry people to the official source. Our personal clones can (and I believe, should) remain on GitHub, since it makes for a very nice way to collaborate. We should however try to get everything rebased against the same commit tree. :-) Also, for the sake of GitHub's pretty graphs, we should also build our repositories by using the "Fork" mechanism. My repository on GitHub is currently in sync with the above (except that `trunk` is a local branch and `master` contains some other stuff). If we decide on a central "fork point", I will recreate the GitHub repo based on that fork and then fold in my changes *again*. Daniel On Wed, May 20, 2009 at 7:24 PM, Assaf Arkin <ar...@intalio.com> wrote: > On Fri, May 15, 2009 at 4:20 PM, Daniel Spiewak <djspie...@gmail.com> > wrote: > > > My committer creds finally came through! :-) Anyway, I would like to > get > > setup so I can commit to the SVN and push to the Git townhall, but this > > seems to be a somewhat non-trivial process. Critically, I want to be > able > > to preserve all of the branches (both local and remote) and > customizations > > that I've built up as part of my GitHub fork. Any suggestions on the > best > > way to do this? Actually, this should probably be on a wiki page > > somewhere, > > but until then... > > > my git-svn is still broken, though I did progress into a different error > (and infinite loop on svn fetch) since upgrading to 1.6.3.1, so right now > I'm not the best person to ask :-) > > > > > > > > Daniel > > >
