I'll simply quote Assaf from a few weeks ago: "Git-svn is the worse of Git and the worse of SVN"
I have very low expectations that we'll find a suitable solution until we officially migrate to Git at Apache. Personally, I'm through playing merge roulette with git-svn... alex PS: I merged your "separate-scala-specs" branch so no need to sweat through that one. On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <djspie...@gmail.com> wrote: > Those of you following development progress using Git are probably starting > to notice that the classical "Vic Master" is no longer the all-knowing > source of data. Actually, Assaf's GitHub fork has become the more > trustworthy one. This is because upon its exit from incubation, Buildr > gets > to move its SVN repository to a new URL. This is good for the project, but > bad for the Git forks since git-svn stores the URL information in its > commit > messages. > > The solution of course is to re-clone from SVN, which I assume exactly what > Assaf did. There result is a repository which contains all of the same SVN > commits as Vic's, but different messages and very different SHA1 revisions, > meaning that Git has a much harder time merging between the two. I > discovered this when I attempted to merge Assaf's latest changes with my > master (forked from Vic's). 57 conflicts later (all petty, little issues > unrelated to my additions), I finally had a working master with the latest > commits. Unfortunately, when I cloned Assaf's repository directly and > attempted to merge back some of my changes, it became very apparent that I > would need to fix the issue in a more scientific manner. > > Long story short, the solution is to rebase all of your branches onto > Assaf's master. I did this by finding the exact commit where I diverged > from vic (I had it tagged, actually) as well as the corresponding commit in > Assaf's master. These commits I tagged "branch-point" and > "new-branch-point", respectively. Then for each branch, I did something > like the following: > > git checkout scala-joint-compilation > git rebase new-branch-point > > Once this was done, I went back to my master and performed a similar > procedure: > > git checkout master > git rebase -s ours new-branch-point > > This effectively wiped out all of my changes in that branch (it's possible > that some commits may remain if you try it, but none did in my case). Once > this was done, I went and picked through my origin/master log to see what I > was missing. This meant re-merging all of my branches: > > git merge scala-joint-compilation > git merge clojure > ... > > Also, I had to cherry-pick a few commits that I had done on master (like > four or five): > > git cherry-pick all-your-ant-base > ... > > Once this was done, I pushed the result back to GitHub: > > git push -f origin > > The one caveat to this approach is I had all of my changes on numerous > separate branches (for patching reasons). All of these branches were > branched off of the same point on vic/master. Since there hadn't been any > merging *between* the branches (only onto master), it was fairly easy to > just rebase these branches onto the new trunk (I only had three conflicts > in > the whole process, all easily resolved). Just judging by GitHub, not many > people are managing their repositories in this fashion. However, this does > mean that you could be able to just rebase without the "-s ours" on your > master and come to the same result. > > The point is that you will need to perform some conniptions of this sort in > order to fix your repositories, otherwise your changes will remain > incompatible with the Buildr mainline trunk: you won't be able to (easily) > merge assaf/master, and he won't be able to (easily) pull from you. > > Incidentally, if anyone has a *better* way of doing this (particularly one > where the entire master history doesn't get wiped out), I'm all ears! I do > still have the unmerged repository sitting in Time Machine, so I'm > perfectly > willing to roll-forward a copy and try again if the result turns out to be > more correct. > > Daniel >
