On Wed, May 20, 2009 at 6:08 PM, Daniel Spiewak <djspie...@gmail.com> wrote:
> :-) 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*. +1 to all of these points. Assaf > > > 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 > > > > > >
