{"thread":{"id":"12752","subject":"git svn rebase horror","startedAt":"2008-03-18T18:51:10Z","lastAt":"2008-03-19T20:39:08Z","messageCount":2,"participants":["Alexander Gladysh","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72381","messageId":"c6c947f60803181151k63e9ce26oca97b36c0d542593@mail.gmail.com","threadId":"12752","inReplyTo":null,"subject":"git svn rebase horror","fromName":"Alexander Gladysh","fromEmail":"agladysh@gmail.com","sentAt":"2008-03-18T18:51:10Z","receivedAt":"2008-03-18T18:51:10Z","isPatch":false,"sender":{"key":"agladysh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38239?v=4"},"body":"Hi, list!\n\nOkay, I know I've done it against all recommendations and must face\nthe consequences.\n\nMy repo is created with git svn init -s. My master branch is thus a\nclone of \"upstream\" svn repo trunk.\n\nCouple of weeks ago I branched from master to what I thought would be\na small feature branch. I often use such branches, implement a small\nfeature there, merge it back to master and delete the branch. This\nhelps task switching, usually works fine and git svn rebase rarely\nconflicts.\n\nWhen I rose my sight from the code I found that my \"small\" feature\nbranch is now +10/-3 KLOC to the master and consists of about 220\ncommits. I've regularly merged in new changes from the master to my\nfeature branch, and occasionally cherry-picked an urgent commit or two\nfrom the branch to the master.\n\nNow the dreaded time came when this feature is done and I have to\nmerge it back to master and dcommit it to svn. I successfully merged\n(fast-forward) from branch to master, but, as expected, when I do git\nsvn rebase it spits conflicts at every third patch.  (Without svn\nrebase, svn dcomit would complain that it does not know how to commit\na merge.) From previous encounters I know that to tame that beast I\nhave to spend at least a day beating conflicts (git rerere and git\nmergetool help a lot, but still require manual work on confirmation).\nAlso the chances to mess something up during dumb manual conflict\nresolution are quite high.\n\nThe git merge --squash is an option. However I obviously  do not want\nto commit it as whole 10KLOC blob. To split that amount of changes to\nindividual \"feature-commits\" is an intense and time-consuming manual\nwork (while more pleasant then conflict resolving). I'd prefer to have\nan automated solution.\n\nFrankly (as I'm quite a dilettante with git), I do not completely\nunderstand the reasons for all the conflicts. The \"endpoint\" version\nof code is already known -- since I've successfully merged two\nbranches. All steps to get that version must be known as well -- full\nhistory tree is available. Except, as I think, that SHA1 for\ncherry-picked commits are different -- due to that git-svn-id: thingy.\nBut perhaps merge process can be taught to handle it? Or does the\nreason for the conflicts lurk somewhere else?\n\nOr, perhaps I need some \"their\" merge strategy (as opposed to \"ours\")?\n\nAny advise?\n\nThanks in advance,\nAlexander.\n"},{"id":"72399","messageId":"alpine.LNX.1.00.0803191616240.19665@iabervon.org","threadId":"12752","inReplyTo":"c6c947f60803181151k63e9ce26oca97b36c0d542593@mail.gmail.com","subject":"Re: git svn rebase horror","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-03-19T20:39:08Z","receivedAt":"2008-03-19T20:39:08Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 18 Mar 2008, Alexander Gladysh wrote:\n\n> Frankly (as I'm quite a dilettante with git), I do not completely\n> understand the reasons for all the conflicts. The \"endpoint\" version\n> of code is already known -- since I've successfully merged two\n> branches. All steps to get that version must be known as well -- full\n> history tree is available. Except, as I think, that SHA1 for\n> cherry-picked commits are different -- due to that git-svn-id: thingy.\n> But perhaps merge process can be taught to handle it? Or does the\n> reason for the conflicts lurk somewhere else?\n\nThe fundamental problem is that you've got:\n\n a - b - - - c\n  \\   \\       \\\n   d - e - f - g\n\nIn 'e', you resolved conflicts between 'b' and 'd'. In 'g', you resolved \nconflicts between 'c' and 'f', but anything that changed in 'd', 'f', and \n'c' is going to be a problem, because for the replacement for 'd', you \nneed something that includes 'c', includes 'd', and doesn't include 'f', \nwhich isn't 'e' (doesn't have 'c') or 'g' (does have 'f').\n\nOf course, you probably don't *really* care about what goes in the new \n'd', because it's going to be replaced in 'f' anyway. But in order to have \na complete history, you need to either make something up or squash such \nthat there's no state in between like that.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}