On Tue, 18 Mar 2008, Alexander Gladysh wrote: > 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* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
