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