Welcome to Rebase Hell!

[Daniel Spiewak]

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

[Alex Boisvert-3]

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@...> 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
>

[Daniel Spiewak]

> PS:  I merged your "separate-scala-specs" branch so no need to sweat
> through
> that one.


Cool!  Did you get some of the more recent changes (documentation and RSpec
specs)?  I think I may have also changed some behavior somewhere to be more
in-line with how Buildr's other test frameworks behave (probably failure).

Daniel

[Assaf Arkin]

On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <djspiewak@...> 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.

Thanks.


AFAIK it's not possible to git svn clone directly from svn.apache.org due to
some weird restriction they placed on the SVN server, it will just keep
git-svn hanging forever. Somehow that doesn't affect incubator projects, or
svn.eu.apache.org, although my starting point was Jukka's unofficial but
somewhat official git mirror[1].


When you git log, check the git-svn-id:

commit a3ab30a66a092bf730950bd95a1394253ebd2f39

Author: Assaf Arkin <assaf@...>

Date:   Fri Feb 27 22:24:50 2009 +0000


>     Fixed RDoc 2.3/2.4 conflict on rake setup.



    git-svn-id:
https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68


If two repositories use a different URL -- look for http vs https,
svn.eu.apache.org vs svn.apache.org, asf/buildr vs asf/incubator/buildr --
Git considers them distinct trees (branches). Any time you merge, Git will
have to merge the entire history of these two branches, leading to a lot of
conflicts.

So if you have branches with changes, follow Daniel's instructions. If you
don't, you can still use the -s ours strategy to "switch" from one branch to
another.

Until Apache comes with a better solution, I'm going to keep my
repository synchronized against  https://svn.eu.apache.org/repos/asf/buildr.
I suggest you all do the same, that way we have the same history and can
easily merge with each other.

Assaf

[1] http://jukka.zitting.name/git/



>
>
> Daniel
>