buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <boisv...@intalio.com>
Subject Re: Welcome to Rebase Hell!
Date Sun, 01 Mar 2009 05:05:48 GMT
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 <djspiewak@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message