{"thread":{"id":"23179","subject":"Rebasing with merges and conflict resolutions","startedAt":"2010-03-26T03:11:12Z","lastAt":"2010-03-26T18:11:01Z","messageCount":5,"participants":["R. Tyler Ballance","Johannes Sixt","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"137823","messageId":"20100326031111.GB27737@kiwi.sharlinx.com","threadId":"23179","inReplyTo":null,"subject":"Rebasing with merges and conflict resolutions","fromName":"R. Tyler Ballance","fromEmail":"tyler@monkeypox.org","sentAt":"2010-03-26T03:11:12Z","receivedAt":"2010-03-26T03:11:12Z","isPatch":false,"sender":{"key":"tyler@monkeypox.org","avatar":"https://gravatar.com/avatar/f523ae06c1aa78f1b4c13bd5dd6fe4c716ec72c0857fcb187f1c7f0e2d2b0ba1?d=mp&s=160"},"body":"I am trying to use rebase to straighten out a couple topic branches' histories\nand running into nothing but troubles and I'm wondering if:\n   a) I'm doing it wrong (highly likely)\n   b) what I want is not possible\n   c) banana!\n\nTwo contributors worked in tandem on a particular project, constantly merging\nback and forth between each other creating a history of 118 commits total with\n37 of them being merge commits, 7 of those merge commits having conflict\nresolutions involved.\n\nI would /like/ to rebase those into a more linear revision history, but I\ncan't seem to find any set of commands that doesn't have me:\n   a) Manually re-doing every conflict resolution and merge (git rebase -p master)\n   b) Drastically diverging from the original topic branch and entering some\n      sort of mergeless hell (git rebase master)\n\n\nIs it even possible to straighten this out without a massive rework of these\ncommits?\n\nIn the future, is there a better way for two developers to work in the same\nback-and-forth fashion (code ping pong!) without leading to *heavily* merged\nhistories that are unpossible to untangle?\n\n\nHalp!\n\n\nCheers,\n-R. Tyler Ballance\n--------------------------------------\n Jabber: rtyler@jabber.org\n GitHub: http://github.com/rtyler\nTwitter: http://twitter.com/agentdero\n   Blog: http://unethicalblogger.com\n\n"},{"id":"137831","messageId":"4BAC5C14.4060903@viscovery.net","threadId":"23179","inReplyTo":"20100326031111.GB27737@kiwi.sharlinx.com","subject":"Re: Rebasing with merges and conflict resolutions","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-26T07:02:44Z","receivedAt":"2010-03-26T07:02:44Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Please don't set Mail-Followup-To on this list.\n\nAm 3/26/2010 4:11, schrieb R. Tyler Ballance:\n> Two contributors worked in tandem on a particular project, constantly merging\n> back and forth between each other creating a history of 118 commits total with\n> 37 of them being merge commits, 7 of those merge commits having conflict\n> resolutions involved.\n> \n> I would /like/ to rebase those into a more linear revision history, but I\n> can't seem to find any set of commands that doesn't have me:\n>    a) Manually re-doing every conflict resolution and merge (git rebase -p master)\n>    b) Drastically diverging from the original topic branch and entering some\n>       sort of mergeless hell (git rebase master)\n\nI'm afraid you can't avoid the merge conflict resolutions. But you can let\nyou help by git-rerere. Look into the script rerere-train.sh that lets you\nprime your rerere database.\n\nhttp://repo.or.cz/w/alt-git.git/blob_plain/master:/contrib/rerere-train.sh\n\n> Is it even possible to straighten this out without a massive rework of these\n> commits?\n\nI would sort the commits into topics and then repeatedly rebase -i the\nhistory involved onto the same commit, each time removing those commits\nthat do not belong to the topic. That is, you get a forest of topics\nsprouting from the same commit. Finally, merge the topics back together.\n\nIOW, I wouldn't aim at a completely linear history, at least not at the\nfirst try.\n\n> In the future, is there a better way for two developers to work in the same\n> back-and-forth fashion (code ping pong!) without leading to *heavily* merged\n> histories that are unpossible to untangle?\n\nDiscipline. Keep developers focused on their topic. Merge only after a\ntopic is completed. Do not give in to \"oh, *your* feature is cool, *I*\nwant to have it now, so I merge it\".\n\n-- Hannes\n"},{"id":"137876","messageId":"20100326171603.GA12592@kiwi.sharlinx.com","threadId":"23179","inReplyTo":"4BAC5C14.4060903@viscovery.net","subject":"Re: Rebasing with merges and conflict resolutions","fromName":"R. Tyler Ballance","fromEmail":"tyler@monkeypox.org","sentAt":"2010-03-26T17:16:04Z","receivedAt":"2010-03-26T17:16:04Z","isPatch":false,"sender":{"key":"tyler@monkeypox.org","avatar":"https://gravatar.com/avatar/f523ae06c1aa78f1b4c13bd5dd6fe4c716ec72c0857fcb187f1c7f0e2d2b0ba1?d=mp&s=160"},"body":"\nOn Fri, 26 Mar 2010, Johannes Sixt wrote:\n\n> Please don't set Mail-Followup-To on this list.\n> \n> Am 3/26/2010 4:11, schrieb R. Tyler Ballance:\n> > Two contributors worked in tandem on a particular project, constantly merging\n> > back and forth between each other creating a history of 118 commits total with\n> > 37 of them being merge commits, 7 of those merge commits having conflict\n> > resolutions involved.\n> > \n> > I would /like/ to rebase those into a more linear revision history, but I\n> > can't seem to find any set of commands that doesn't have me:\n> >    a) Manually re-doing every conflict resolution and merge (git rebase -p master)\n> >    b) Drastically diverging from the original topic branch and entering some\n> >       sort of mergeless hell (git rebase master)\n> \n> I'm afraid you can't avoid the merge conflict resolutions. But you can let\n> you help by git-rerere. Look into the script rerere-train.sh that lets you\n> prime your rerere database.\n> \n> http://repo.or.cz/w/alt-git.git/blob_plain/master:/contrib/rerere-train.sh\n> \n> > Is it even possible to straighten this out without a massive rework of these\n> > commits?\n> \n> I would sort the commits into topics and then repeatedly rebase -i the\n> history involved onto the same commit, each time removing those commits\n> that do not belong to the topic. That is, you get a forest of topics\n> sprouting from the same commit. Finally, merge the topics back together.\n\nThe problem I'm having with this is that with a `git rebase -p -i master` I\ncan't even squash two related changes that are right next to each other\ntogether because the rebase bails out earlier on conflicts while trying to\nreplay.\n\nPerhaps I'm chosing the incorrect upstream?\n\n> IOW, I wouldn't aim at a completely linear history, at least not at the\n> first try.\n> \n> > In the future, is there a better way for two developers to work in the same\n> > back-and-forth fashion (code ping pong!) without leading to *heavily* merged\n> > histories that are unpossible to untangle?\n> \n> Discipline. Keep developers focused on their topic. Merge only after a\n> topic is completed. Do not give in to \"oh, *your* feature is cool, *I*\n> want to have it now, so I merge it\".\n\nI think that's easier said than done, with backend work I'm able to clearly\ndefine topics, whereas the front-end developers (as it is in this case)\ntypically overlap ever so slightly in their work\n\nCheers,\n-R. Tyler Ballance\n--------------------------------------\n Jabber: rtyler@jabber.org\n GitHub: http://github.com/rtyler\nTwitter: http://twitter.com/agentdero\n   Blog: http://unethicalblogger.com\n\n"},{"id":"137877","messageId":"2cfc40321003261036n7bfe402co8084824f6222a841@mail.gmail.com","threadId":"23179","inReplyTo":"20100326031111.GB27737@kiwi.sharlinx.com","subject":"Re: Rebasing with merges and conflict resolutions","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-03-26T17:36:24Z","receivedAt":"2010-03-26T17:36:24Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"You might find this post from a few weeks back interesting:\n\n    http://permalink.gmane.org/gmane.comp.version-control.git/140510\n\nUnfortunately, I haven't had time to reproduce a robust implementation\nof the ideas, but I have exercised the algorithm manually a few times\nand it works quite well.\n\nThe basic idea is that you split the merge history into segments\n(where a segment is a single linear series of commits). Then starting\nfrom the oldest you rewrite:\n\nA----B---M\n  \\---C---/\n\nas:\n\nA---B---e---C'---e'---M'\n\nwhere e is a compensation that allows e to be automatically rebased\nonto B without merge conflicts and e' restores the tree to the point\nit was an M so that tree(M) and tree(M') are identical. See the\noriginal post for working out how to construct e and e'. The basic\nidea is you find the confllcts that would result if you attempted\nrebase C on B, then reset part of the tree in such a way that the\nconflicts are removed. e' then is the patch that restores tree(C') to\ntree(M)\n\nYou have to realise that the trees between e and e' will be\ninconsistent because part of the tree is shifted back in time in order\nto allow the C to rebase cleanly.\n\nOnce the history is linearised in this way, it is often (but not\nalways) possible to reorder and then squash the commits in  e --- C'\n--- e' such away that the consistency of the tree in this region is\nrestored.\n\nif you repeat this algorithm recursively for each merge in the merge\nhistory you can flatten the entire merge history out into a linear\nseries of commits. This can be complete and automatic, alhough to\nobtain completeness you do lose consistency at certain well-delimited\npoints in the history. Consistency can be restored, if required, by\nmanually rebasing the linearised history in a single pass at the end.\n\nI do intend to commit the algorithm to code at some point, but haven't\nhad a chance to do so yet. See ( http://github.com/jonseymour/hammer)\nfor a readme that also describes the idea in more detail\n\njon.\n\nOn Fri, Mar 26, 2010 at 2:11 PM, R. Tyler Ballance <tyler@monkeypox.org> wrote:\n> I am trying to use rebase to straighten out a couple topic branches' histories\n> and running into nothing but troubles and I'm wondering if:\n>   a) I'm doing it wrong (highly likely)\n>   b) what I want is not possible\n>   c) banana!\n>\n> Two contributors worked in tandem on a particular project, constantly merging\n> back and forth between each other creating a history of 118 commits total with\n> 37 of them being merge commits, 7 of those merge commits having conflict\n> resolutions involved.\n>\n> I would /like/ to rebase those into a more linear revision history, but I\n> can't seem to find any set of commands that doesn't have me:\n>   a) Manually re-doing every conflict resolution and merge (git rebase -p master)\n>   b) Drastically diverging from the original topic branch and entering some\n>      sort of mergeless hell (git rebase master)\n>\n>\n> Is it even possible to straighten this out without a massive rework of these\n> commits?\n>\n> In the future, is there a better way for two developers to work in the same\n> back-and-forth fashion (code ping pong!) without leading to *heavily* merged\n> histories that are unpossible to untangle?\n>\n>\n> Halp!\n>\n>\n> Cheers,\n> -R. Tyler Ballance\n> --------------------------------------\n>  Jabber: rtyler@jabber.org\n>  GitHub: http://github.com/rtyler\n> Twitter: http://twitter.com/agentdero\n>   Blog: http://unethicalblogger.com\n>\n>\n"},{"id":"137879","messageId":"2cfc40321003261111x5a500ef4q9b0caea65a48b21f@mail.gmail.com","threadId":"23179","inReplyTo":"20100326171603.GA12592@kiwi.sharlinx.com","subject":"Re: Rebasing with merges and conflict resolutions","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-03-26T18:11:01Z","receivedAt":"2010-03-26T18:11:01Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"> > > In the future, is there a better way for two developers to work in the same\n> > > back-and-forth fashion (code ping pong!) without leading to *heavily* merged\n> > > histories that are unpossible to untangle?\n> >\n> > Discipline. Keep developers focused on their topic. Merge only after a\n> > topic is completed. Do not give in to \"oh, *your* feature is cool, *I*\n> > want to have it now, so I merge it\".\n>\n> I think that's easier said than done, with backend work I'm able to clearly\n> define topics, whereas the front-end developers (as it is in this case)\n> typically overlap ever so slightly in their work\n>\n\nIf two developers are working together, then set them up so that each\nhas a public and private repo.\n\nThe rule should be:\n\n1. before publishing, A fetches from B to ensure that A has B's latest\npublic tip\n2. A confirms that B's tip includes A's public tip\n3. A rebases own private changes (between A public and A private) onto\nB's public tip\n4. A pushes her rebased private tip to her own public repo\n5. B then repeats the cycle with the roles reversed.\n\nThis will work provided that B doesn't republish after 2 and before 4,\nso does require that A and B talk to each other before performing step\n4.\n\njon.\n"}]}