git svn rebase horror

Alexander Gladysh· Mar 18, 2008, 18:51 UTC · lore

Hi, list!

Okay, I know I've done it against all recommendations and must face the consequences.

My repo is created with git svn init -s. My master branch is thus a clone of "upstream" svn repo trunk.

Couple of weeks ago I branched from master to what I thought would be a small feature branch. I often use such branches, implement a small feature there, merge it back to master and delete the branch. This helps task switching, usually works fine and git svn rebase rarely conflicts.

When I rose my sight from the code I found that my "small" feature branch is now +10/-3 KLOC to the master and consists of about 220 commits. I've regularly merged in new changes from the master to my feature branch, and occasionally cherry-picked an urgent commit or two from the branch to the master.

Now the dreaded time came when this feature is done and I have to merge it back to master and dcommit it to svn. I successfully merged (fast-forward) from branch to master, but, as expected, when I do git svn rebase it spits conflicts at every third patch. (Without svn rebase, svn dcomit would complain that it does not know how to commit a merge.) From previous encounters I know that to tame that beast I have to spend at least a day beating conflicts (git rerere and git mergetool help a lot, but still require manual work on confirmation). Also the chances to mess something up during dumb manual conflict resolution are quite high.

The git merge --squash is an option. However I obviously do not want to commit it as whole 10KLOC blob. To split that amount of changes to individual "feature-commits" is an intense and time-consuming manual work (while more pleasant then conflict resolving). I'd prefer to have an automated solution.

Frankly (as I'm quite a dilettante with git), I do not completely understand the reasons for all the conflicts. The "endpoint" version of code is already known -- since I've successfully merged two branches. All steps to get that version must be known as well -- full history tree is available. Except, as I think, that SHA1 for cherry-picked commits are different -- due to that git-svn-id: thingy. But perhaps merge process can be taught to handle it? Or does the reason for the conflicts lurk somewhere else?

Or, perhaps I need some "their" merge strategy (as opposed to "ours")?

Any advise?

Thanks in advance, Alexander.

Daniel Barkalow· Mar 19, 2008, 20:39 UTC · re: Alexander Gladysh · lore

Re: git svn rebase horror

On Tue, 18 Mar 2008, Alexander Gladysh wrote:

Show 8 quoted lines

> Frankly (as I'm quite a dilettante with git), I do not completely
> understand the reasons for all the conflicts. The "endpoint" version
> of code is already known -- since I've successfully merged two
> branches. All steps to get that version must be known as well -- full
> history tree is available. Except, as I think, that SHA1 for
> cherry-picked commits are different -- due to that git-svn-id: thingy.
> But perhaps merge process can be taught to handle it? Or does the
> reason for the conflicts lurk somewhere else?

The fundamental problem is that you've got:

 a - b - - - c
  \   \       \
   d - e - f - g

In 'e', you resolved conflicts between 'b' and 'd'. In 'g', you resolved conflicts between 'c' and 'f', but anything that changed in 'd', 'f', and 'c' is going to be a problem, because for the replacement for 'd', you need something that includes 'c', includes 'd', and doesn't include 'f', which isn't 'e' (doesn't have 'c') or 'g' (does have 'f').

Of course, you probably don't *really* care about what goes in the new 'd', because it's going to be replaced in 'f' anyway. But in order to have a complete history, you need to either make something up or squash such that there's no state in between like that.

	-Daniel
*This .sig left intentionally blank*