Re: git svn rebase horror

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Mar 19, 2008, 20:39 UTC
Message-ID: <alpine.LNX.1.00.0803191616240.19665@iabervon.org>
In-Reply-To: <c6c947f60803181151k63e9ce26oca97b36c0d542593@mail.gmail.com>

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*