{"thread":{"id":"16790","subject":"Odd merge behaviour involving reverts","startedAt":"2008-12-18T23:25:34Z","lastAt":"2008-12-19T23:51:38Z","messageCount":17,"participants":["Alan","Linus Torvalds","Boyd Stephen Smith Jr.","Nanako Shiraishi","Jay Soffian","Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98299","messageId":"1229642734.5770.25.camel@rotwang.fnordora.org","threadId":"16790","inReplyTo":null,"subject":"Odd merge behaviour involving reverts","fromName":"Alan","fromEmail":"alan@clueserver.org","sentAt":"2008-12-18T23:25:34Z","receivedAt":"2008-12-18T23:25:34Z","isPatch":false,"sender":{"key":"alan@clueserver.org","avatar":null},"body":"I am encountering an odd problem with how merging branches are working.\nI expect I am doing something wrong, I just need to know what.\n\nHere is my situation...\n\nI have a master branch. We have a branch off of that that some\ndevelopers are doing work on. They claim it is ready. We merge it into\nthe master branch. It breaks something so we revert the merge. They\nmake changes to the code. they get it to a point where they say it is\nok and we merge again.\n\nWhen examined, we find that code changes made before the revert are not\nin the master branch, but code changes after are in the master branch.\n\nWe now have code that does not contain all of the changes in the branch.\n\nIs there a different way to undo merges into a branch that does not\nblock further merges from that branch?\n\nWhat am i doing wrong here?\n"},{"id":"98302","messageId":"alpine.LFD.2.00.0812181534310.14014@localhost.localdomain","threadId":"16790","inReplyTo":"1229642734.5770.25.camel@rotwang.fnordora.org","subject":"Re: Odd merge behaviour involving reverts","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-12-18T23:58:37Z","receivedAt":"2008-12-18T23:58:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 18 Dec 2008, Alan wrote:\n> \n> What am i doing wrong here?\n\nReverting a merge is your problem.\n\nYou can do it, but you seem to have done it without understanding what it \ncauses.\n\nA revert of a merge becomes a regular commit that just undoes everything \nthat the merge did in your branch. When you then do the next merge, you'll \ndo that merge with that in mind, so now git will essentially consider the \nprevious merge to be the base line, but your revert undid everything that \nthat one brought in, so the new merge will really only contain the new \nstuff from the branch you are merging. \n\nSo if a merge causes problems, you generally should either undo it \n_entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it. \n\nOf course, if you had already made the merged state public, or done \ndevelopment on top of it, you can't really do that. In which case a revert \nworks, but if you want it back, you should revert the revert, not merge \nthe branch again - because what you merged last time you threw away, and \nwon't be applied again.\n\n\t\tLinus\n"},{"id":"98305","messageId":"1229645511.5770.29.camel@rotwang.fnordora.org","threadId":"16790","inReplyTo":"alpine.LFD.2.00.0812181534310.14014@localhost.localdomain","subject":"Re: Odd merge behaviour involving reverts","fromName":"Alan","fromEmail":"alan@clueserver.org","sentAt":"2008-12-19T00:11:51Z","receivedAt":"2008-12-19T00:11:51Z","isPatch":false,"sender":{"key":"alan@clueserver.org","avatar":null},"body":"On Thu, 2008-12-18 at 15:58 -0800, Linus Torvalds wrote:\n> \n> On Thu, 18 Dec 2008, Alan wrote:\n> > \n> > What am i doing wrong here?\n> \n> Reverting a merge is your problem.\n> \n> You can do it, but you seem to have done it without understanding what it \n> causes.\n\nObviously.\n\n> A revert of a merge becomes a regular commit that just undoes everything \n> that the merge did in your branch. When you then do the next merge, you'll \n> do that merge with that in mind, so now git will essentially consider the \n> previous merge to be the base line, but your revert undid everything that \n> that one brought in, so the new merge will really only contain the new \n> stuff from the branch you are merging. \n\nSo I will have to look for previous reverts (or \"pre-verts\") before\nmerging again.\n\n> So if a merge causes problems, you generally should either undo it \n> _entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it. \n> \n> Of course, if you had already made the merged state public, or done \n> development on top of it, you can't really do that. In which case a revert \n> works, but if you want it back, you should revert the revert, not merge \n> the branch again - because what you merged last time you threw away, and \n> won't be applied again.\n\nOn this code base, there were 30+ branches merged before the powers that\nbe decided to have me pull that one. It was in the middle of the pile.\n\nI think I know how to fix it. I am just concerned about having it occur\nagain if someone else makes the same mistake I did.\n\nThanks.\n"},{"id":"98307","messageId":"alpine.LFD.2.00.0812181614070.14014@localhost.localdomain","threadId":"16790","inReplyTo":"1229645511.5770.29.camel@rotwang.fnordora.org","subject":"Re: Odd merge behaviour involving reverts","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-12-19T00:21:25Z","receivedAt":"2008-12-19T00:21:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 18 Dec 2008, Alan wrote:\n> \n> I think I know how to fix it. I am just concerned about having it occur\n> again if someone else makes the same mistake I did.\n\nI suspect we should warn about reverting merges. I'm surprised we don't \nalready. Reverting a merge isn't \"wrong\", but it's a whole lot more subtle \nthan reverting a regular commit.\n\nReverting a regular commit just effectively undoes what that commit did, \nand is fairly straightforward. But reverting a merge commit also undoes \nthe _data_ that the commit changed, but it does absolutely nothing to the \neffects on _history_ that the merge had.\n\nSo the merge will still exist, and it will still be seen as joining the \ntwo branches together, and future merges will see that merge as the last \nshared state - and the revert that reverted the merge brought in will not \naffect that at all.\n\nSo a \"revert\" undoes the data changes, but it's very much _not_ an \"undo\" \nin the sense that it doesn't undo the effects of a commit on the \nrepository history.\n\nSo if you think of \"revert\" as \"undo\", then you're going to always miss \nthis part of reverts. Yes, it undoes the data, but no, it doesn't undo \nhistory.\n\n\t\t\tLinus\n"},{"id":"98310","messageId":"1229646948.5770.33.camel@rotwang.fnordora.org","threadId":"16790","inReplyTo":"alpine.LFD.2.00.0812181614070.14014@localhost.localdomain","subject":"Re: Odd merge behaviour involving reverts","fromName":"Alan","fromEmail":"alan@clueserver.org","sentAt":"2008-12-19T00:35:48Z","receivedAt":"2008-12-19T00:35:48Z","isPatch":false,"sender":{"key":"alan@clueserver.org","avatar":null},"body":"On Thu, 2008-12-18 at 16:21 -0800, Linus Torvalds wrote:\n> \n> On Thu, 18 Dec 2008, Alan wrote:\n> > \n> > I think I know how to fix it. I am just concerned about having it occur\n> > again if someone else makes the same mistake I did.\n> \n> I suspect we should warn about reverting merges. I'm surprised we don't \n> already. Reverting a merge isn't \"wrong\", but it's a whole lot more subtle \n> than reverting a regular commit.\n> \n> Reverting a regular commit just effectively undoes what that commit did, \n> and is fairly straightforward. But reverting a merge commit also undoes \n> the _data_ that the commit changed, but it does absolutely nothing to the \n> effects on _history_ that the merge had.\n> \n> So the merge will still exist, and it will still be seen as joining the \n> two branches together, and future merges will see that merge as the last \n> shared state - and the revert that reverted the merge brought in will not \n> affect that at all.\n> \n> So a \"revert\" undoes the data changes, but it's very much _not_ an \"undo\" \n> in the sense that it doesn't undo the effects of a commit on the \n> repository history.\n> \n> So if you think of \"revert\" as \"undo\", then you're going to always miss \n> this part of reverts. Yes, it undoes the data, but no, it doesn't undo \n> history.\n\nSo what is the recommended way to undo mistaken merges caught after the\nfact that will not fubar later merges?\n"},{"id":"98314","messageId":"alpine.LFD.2.00.0812181637140.14014@localhost.localdomain","threadId":"16790","inReplyTo":"1229646948.5770.33.camel@rotwang.fnordora.org","subject":"Re: Odd merge behaviour involving reverts","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-12-19T00:46:51Z","receivedAt":"2008-12-19T00:46:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 18 Dec 2008, Alan wrote:\n> \n> So what is the recommended way to undo mistaken merges caught after the\n> fact that will not fubar later merges?\n\nOh, I suspect reverting is the right thing, it's just that then you need \nto remember to revert the revert if you intend to merge that branch again \nlater.\n\nSo reverting a merge isn't _wrong_ per se. It's just that you need to be \naware of the consequences, and if it becomes a common situation, you have \na problem in your usage patterns.\n\nBtw, even with non-merge commits, \"revert\" can have interesting effects \nexactly because it doesn't change history. For example, let's say that you \nhad a history like this, with two branches:\n\n\t--> a --> b --> c --> d\n\t |\n\t +-> e --> !a\n\nwhere the second branch reverts 'a', but the first one does not. What \nhappens when you merge the two branches? Is the revert sticky? In this \ncase, yes, a merge will cause the revert to stick. But what happens if you \nhad\n\n\t--> a --> b --> c --> d\n\t |\n\t +-> e --> f --> !e\n\nand 'b' and 'e' were the same patch (just applied in two different \nbranches), and '!e' reverts that patch in the second branch. What happens \nto 'b' when you merge? Would you expect for 'b' to go away, since the \nrevert undid the same data in the second branch?\n\nIn that second case, the revert of 'e' will basically make git act as if \n'e' didn't happen at all in the second branch, and so when you merge them, \n'b' _will_ exist in the end result, so now the revert didn't \"take\".\n\nAll of this is very self-consistent (it's a very direct result of how \nmerges work and how revert works), but I'm just bringing these things up \nas examples of how 'revert' is not a totally trivial matter. You'll always \nfind cases where you might have wished that it had acted differently when \nyou merge things.\n\n\n\n\t\t\tLinus\n"},{"id":"98317","messageId":"200812181930.43782.bss@iguanasuicide.net","threadId":"16790","inReplyTo":"1229642734.5770.25.camel@rotwang.fnordora.org","subject":"Re: Odd merge behaviour involving reverts","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2008-12-19T01:30:40Z","receivedAt":"2008-12-19T01:30:40Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Thursday 2008 December 18 17:25:34 Alan wrote:\n> Here is my situation...\n>\n> I have a master branch.  We have a branch off of that that some\n> developers are doing work on.  They claim it is ready. We merge it into\n> the master branch.  It breaks something so we revert the merge.  They\n> make changes to the code.  they get it to a point where they say it is\n> ok and we merge again.\n>\n> What am i doing wrong here?\n\nDon't do tests on the master branch. Or at least, do as little as possible. Also, try not to revert merges. Depending on your workflow and team synamics it might be easier to rewrite history than wrangle reverts of a merge commit.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"98329","messageId":"20081219124452.6117@nanako3.lavabit.com","threadId":"16790","inReplyTo":"alpine.LFD.2.00.0812181534310.14014@localhost.localdomain","subject":"Re: Odd merge behaviour involving reverts","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2008-12-19T03:44:52Z","receivedAt":"2008-12-19T03:44:52Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Linus Torvalds :\n\n> On Thu, 18 Dec 2008, Alan wrote:\n>> \n>> What am i doing wrong here?\n>\n> Reverting a merge is your problem.\n>\n> You can do it, but you seem to have done it without understanding what it \n> causes.\n>\n> A revert of a merge becomes a regular commit that just undoes everything \n> that the merge did in your branch. When you then do the next merge, you'll \n> do that merge with that in mind, so now git will essentially consider the \n> previous merge to be the base line, but your revert undid everything that \n> that one brought in, so the new merge will really only contain the new \n> stuff from the branch you are merging. \n>\n> So if a merge causes problems, you generally should either undo it \n> _entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it. \n>\n> Of course, if you had already made the merged state public, or done \n> development on top of it, you can't really do that. In which case a revert \n> works, but if you want it back, you should revert the revert, not merge \n> the branch again - because what you merged last time you threw away, and \n> won't be applied again.\n\nIf I understand Alan's case correctly, I think he does not want to \"undo\" the revert but wants to merge an updated version of the branch, as if no mistaken merge nor its revert happened in the past.\n\nIf you revert the revert on the branch before merging, doesn't it mean that you will be merging what the older version of the branch did (that is in the revert of the revert as a single huge patch) and what the updated version of the branch wants to do? Wouldn't that lead to a mess with huge conflicts?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"98332","messageId":"alpine.LFD.2.00.0812181949450.14014@localhost.localdomain","threadId":"16790","inReplyTo":"20081219124452.6117@nanako3.lavabit.com","subject":"Re: Odd merge behaviour involving reverts","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-12-19T04:01:48Z","receivedAt":"2008-12-19T04:01:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 19 Dec 2008, Nanako Shiraishi wrote:\n> \n> If you revert the revert on the branch before merging, doesn't it mean \n> that you will be merging what the older version of the branch did (that \n> is in the revert of the revert as a single huge patch) and what the \n> updated version of the branch wants to do? Wouldn't that lead to a mess \n> with huge conflicts?\n\nActually, the reverse is likely true. If the branch you are merging is \nactually doing something branch-specific - ie it's a \"topic branch\", then \nit's likely that the new stuff that is on that branch depends on the \nprevious stuff on the branch.\n\nAnd thats' the thing that got reverted - so with just a revert, it's quite \nlikely that you'll get conflicts. But if you revert the revert, now the \nnew stuff you're merging actually makes more sense, and is less likely to \nconflict.\n\nAnother way of looking at it is that a merge is something that can be done \nboth ways: think of the _other_ branch merging yours. The original revert \nends up being a big change-patch that undoes everything that other branch \ndid, so now if that other branch were to merge the main branch, you'd be \nmerging a lot of changes. But reverting the revert will undo all those \nchanges, so again, it's more likely that the merge will succeed.\n\nSo revertign a revert is usually going to make subsequent merges easier \nrather than the reverse. \n\nThe _big_ problem with reverting a whole merge is that it effectively \nbecomes one commit that does a big change. That's how _normal_ merges tend \nto look like in CVS or SVN (ie the \"merge\" is really just another commit \nthat brings in a lot of changes), and it's a total and utter f*cking \ndisaster!\n\nBut don't get me wrong - it's not something you can't work with. I'm just \ntrying to say that it's absolutely not a \"good model\". It's workable, but \nit has all these painful issues.\n\nFor example, think about what reverting a merge (and then reverting the \nrevert) does to bisectability. Ignore the fact that the revert of a revert \nis undoing it - just think of it as a \"single commit that does a lot\". \nBecause that is what it does.\n\nWhen you have a problem you are chasing down, and you hit a \"revert this \nmerge\", what you're hitting is essentially a single commit that contains \nall the changes (but obviously in reverse) of all the commits that got \nmerged. So it's debugging hell, because now you don't have lots of small \nchanges that you can try to pinpoint which _part_ of it changes.\n\nBut does it all work? Sure it does. You can revert a merge, and from a \npurely technical angle, git did it very naturally and had no real \ntroubles. It just considered it a change from \"state before merge\" to \n\"state after merge\", and that was it. Nothing complicated, nothing odd, \nnothing really dangerous. Git will do it without even thinking about it.\n\nSo from a technical angle, there's nothing wrong with reverting a merge, \nbut from a workflow angle it's something that you generally should try to \navoid. \n\nIf at all possible, for example, if you find a problem that got merged \ninto the main tree, rather than revert the merge, try _really_ hard to \nbisect the problem down into the branch you merged, and just fix it, or \ntry to revert the individual commit that caused it.\n\nYes, it's more complex, and no, it's not always going to work (sometimes \nthe answer is: \"oops, I really shouldn't have merged it, because it wasn't \nready yet, and I really need to undo _all_ of the merge\"). So then you \nreally should revert the merge, but when you want to re-do the merge, you \nnow need to do it by reverting the revert.\n\n\t\tLinus\n"},{"id":"98333","messageId":"76718490812182018x37e3d6fob8d817c0e0b0e293@mail.gmail.com","threadId":"16790","inReplyTo":"alpine.LFD.2.00.0812181949450.14014@localhost.localdomain","subject":"Re: Odd merge behaviour involving reverts","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-12-19T04:18:56Z","receivedAt":"2008-12-19T04:18:56Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Dec 18, 2008 at 11:01 PM, Linus Torvalds\n wrote:\n> Yes, it's more complex, and no, it's not always going to work (sometimes\n> the answer is: \"oops, I really shouldn't have merged it, because it wasn't\n> ready yet, and I really need to undo _all_ of the merge\"). So then you\n> really should revert the merge, but when you want to re-do the merge, you\n> now need to do it by reverting the revert.\n\nInstead of reverting the revert, why not rebase the branch which was\nmerged to the point after the revert was done?\n\nj.\n"},{"id":"98334","messageId":"alpine.LFD.2.00.0812182022170.14014@localhost.localdomain","threadId":"16790","inReplyTo":"76718490812182018x37e3d6fob8d817c0e0b0e293@mail.gmail.com","subject":"Re: Odd merge behaviour involving reverts","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-12-19T04:23:16Z","receivedAt":"2008-12-19T04:23:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 18 Dec 2008, Jay Soffian wrote:\n> \n> Instead of reverting the revert, why not rebase the branch which was\n> merged to the point after the revert was done?\n\nSure, you can do that too. However, that has its own set of problems, ie \nall the \"ok, who else was working based on this branch\" thing.\n\nBut no, there are no single right answers. Rebasing may well be a \nreasonable approach.\n\n\t\tLinus\n"},{"id":"98336","messageId":"alpine.LNX.1.00.0812182353490.19665@iabervon.org","threadId":"16790","inReplyTo":"alpine.LFD.2.00.0812181949450.14014@localhost.localdomain","subject":"Re: Odd merge behaviour involving reverts","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-19T05:24:01Z","receivedAt":"2008-12-19T05:24:01Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 18 Dec 2008, Linus Torvalds wrote:\n\n> On Fri, 19 Dec 2008, Nanako Shiraishi wrote:\n> > \n> > If you revert the revert on the branch before merging, doesn't it mean \n> > that you will be merging what the older version of the branch did (that \n> > is in the revert of the revert as a single huge patch) and what the \n> > updated version of the branch wants to do? Wouldn't that lead to a mess \n> > with huge conflicts?\n> \n> Actually, the reverse is likely true. If the branch you are merging is \n> actually doing something branch-specific - ie it's a \"topic branch\", then \n> it's likely that the new stuff that is on that branch depends on the \n> previous stuff on the branch.\n> \n> And thats' the thing that got reverted - so with just a revert, it's quite \n> likely that you'll get conflicts. But if you revert the revert, now the \n> new stuff you're merging actually makes more sense, and is less likely to \n> conflict.\n> \n> Another way of looking at it is that a merge is something that can be done \n> both ways: think of the _other_ branch merging yours. The original revert \n> ends up being a big change-patch that undoes everything that other branch \n> did, so now if that other branch were to merge the main branch, you'd be \n> merging a lot of changes. But reverting the revert will undo all those \n> changes, so again, it's more likely that the merge will succeed.\n> \n> So revertign a revert is usually going to make subsequent merges easier \n> rather than the reverse. \n> \n> The _big_ problem with reverting a whole merge is that it effectively \n> becomes one commit that does a big change. That's how _normal_ merges tend \n> to look like in CVS or SVN (ie the \"merge\" is really just another commit \n> that brings in a lot of changes), and it's a total and utter f*cking \n> disaster!\n\nAnother option is to do the big revert on the master branch, and on the \nside branch merge the parent of the revert (normally), and then merge the \nrevert but take the side branch tree.\n\nThat last merge puts the revert in the branch's history, but rejects its \neffects. Now merging the branch again will find the revert to be the \ncommon ancestor, and see the full change of the side branch as the \ncontribution of that side. Also, blame will come down the side branch, \nignore the merge (on the side branch, the merge contributed no content \nchanges), and go into the original side branch commits.\n\nYou can also think of it as the side branch saying, \"I noticed that you \nreverted my changes, but I'm keeping them anyway\". When the final merge \ncomes, git will see that the revert isn't new information to the side \nbranch, and nullify its effect. (Of course, the side branch needs to merge \nthe parent of the revert so that it isn't rejecting the other changes made \non the main branch before the revert)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"98345","messageId":"7vocz8a6zk.fsf@gitster.siamese.dyndns.org","threadId":"16790","inReplyTo":"20081219124452.6117@nanako3.lavabit.com","subject":"Re: Odd merge behaviour involving reverts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-19T08:45:19Z","receivedAt":"2008-12-19T08:45:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> If I understand Alan's case correctly, I think he does not want to\n> \"undo\" the revert but wants to merge an updated version of the branch,\n> as if no mistaken merge nor its revert happened in the past.\n>\n> If you revert the revert on the branch before merging, doesn't it mean\n> that you will be merging what the older version of the branch did (that\n> is in the revert of the revert as a single huge patch) and what the\n> updated version of the branch wants to do? Wouldn't that lead to a mess\n> with huge conflicts?\n\nThe history immediately after the \"revert of the merge\" would look like\nthis:\n\n ---o---o---o---M---x---x---W---x\n / \n ---A---B\n\nwhere A and B are on the side development that was not so good, M is the\nmerge that brings those premature changes into the mainline, x are\nunrelated changes already made on the mainline and W is the \"revert of the\nmerge M\" (doesn't W look M upside down?). IOW, \"diff W^..W\" is similar to\n\"diff -R M^..M\".\n\nI think you misunderstood what \"merging an updated version of the branch\"\nmeant by Alan's description to mean that the side branch developers\ndiscarded their faulty A and B, and redone the changes, which would have\nresulted in something like:\n\n ---o---o---o---M---x---x---W---x---x\n \\\n A'--B'--C'\n\nIf that were the situation, suggestion by Linus to revert the revert and\nthen merge would result in something like this:\n\n ---o---o---o---M---x---x---W---x---x---Y---*\n \\ /\n A'--B'--C'\n\nwhere Y is the revert of W, A' and B'are rerolled A and B, and there may\nalso be a further fix-up C' on the side branch. \"diff Y^..Y\" is similar\nto \"diff -R W^..W\" (which in turn means it is similar to \"diff M^..M\"),\nand \"diff A'^..C'\" by definition would be similar but different from that,\nbecause it is a rerolled series of the earlier change. There would be a\nlot of overlap as you feared. In such a case, not having Y (revert of the\nrevert) would result in a much more trivial merge:\n\n ---o---o---o---M---x---x---W---x---x-------*\n \\ /\n A'--B'--C'\n\nbecause problematic large commits M and W are already outside of the scope\nof this final merge.\n\nBut I think what Alan's developers did is different. They did this\ninstead:\n\n ---o---o---o---M---x---x---W---x\n /\n ---A---B-------------------C---D\n\nwhere C and D are to fix what was broken in A and B. In such a situation,\nwhat Linus suggests makes perfect sense. You first revert the revert,\nwhich would result in this:\n\n ---o---o---o---M---x---x---W---x---Y\n /\n ---A---B-------------------C---D\n\nwhere Y is the revert of W, which would (ignoring possible conflicts\nbetween what W and W..Y changed) be equivalent to not having W nor Y at\nall in the history:\n\n ---o---o---o---M---x---x-------x----\n /\n ---A---B-------------------C---D\n\nand merging the side branch again will not have conflict arising from an\nearlier revert and revert of revert.\n\n ---o---o---o---M---x---x-------x-------*\n / /\n ---A---B-------------------C---D\n\nOf course the changes made in C and D still can conflict with what was\ndone by any of the x, but that is just a normal merge conflict.\n\nTo recap, these are two very different scenarios, and wants two very\ndifferent resolution strategies:\n\n - If the faulty side branch whose effects were discarded by an earlier\n revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,\n as you seem to have interpreted), then re-merging the result without\n doing anything else fancy would be the right thing to do.\n\n - If the faulty side branch was fixed by adding corrections on top, then\n doing a revert of the previous revert would be the right thing to do.\n\nI hope this clears up confusion and fear.\n"},{"id":"98376","messageId":"20081220064532.6117@nanako3.lavabit.com","threadId":"16790","inReplyTo":"7vocz8a6zk.fsf@gitster.siamese.dyndns.org","subject":"Re: Odd merge behaviour involving reverts","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2008-12-19T21:45:32Z","receivedAt":"2008-12-19T21:45:32Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> I hope this clears up confusion and fear.\n\nYou are correct that I misunderstood what Alan meant by corrected branch.\n\nI think your explanation will help people if we make it part of the documentation. Especially because two different cases need two different recovery methods, and people need to learn which is which.\n\nThank you for your detailed response.\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"98385","messageId":"7vljub7oko.fsf@gitster.siamese.dyndns.org","threadId":"16790","inReplyTo":"20081220064532.6117@nanako3.lavabit.com","subject":"Re: Odd merge behaviour involving reverts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-19T23:05:59Z","receivedAt":"2008-12-19T23:05:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> I think your explanation will help people if we make it part of the\n> documentation. Especially because two different cases need two\n> different recovery methods, and people need to learn which is which.\n\nSure. It needs copyediting to make it readable standalone by not\nmentioning \"your misunderstanding\", inlining \"earlier Linus's suggestion\",\netc., though.\n\nPatches welcome ;-)\n"},{"id":"98388","messageId":"20081220081238.6117@nanako3.lavabit.com","threadId":"16790","inReplyTo":"7vljub7oko.fsf@gitster.siamese.dyndns.org","subject":"Re: Odd merge behaviour involving reverts","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2008-12-19T23:12:38Z","receivedAt":"2008-12-19T23:12:38Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> Nanako Shiraishi writes:\n>\n>> I think your explanation will help people if we make it part of the\n>> documentation. Especially because two different cases need two\n>> different recovery methods, and people need to learn which is which.\n>\n> Sure. It needs copyediting to make it readable standalone by not\n> mentioning \"your misunderstanding\", inlining \"earlier Linus's suggestion\",\n> etc., though.\n>\n> Patches welcome ;-)\n\nOkay, I'll send one later.\n\nThanks.\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"98395","messageId":"7vwsdv67w5.fsf@gitster.siamese.dyndns.org","threadId":"16790","inReplyTo":"20081220081238.6117@nanako3.lavabit.com","subject":"Re: Odd merge behaviour involving reverts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-19T23:51:38Z","receivedAt":"2008-12-19T23:51:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Quoting Junio C Hamano :\n>\n>> Nanako Shiraishi writes:\n>>\n>>> I think your explanation will help people if we make it part of the\n>>> documentation. Especially because two different cases need two\n>>> different recovery methods, and people need to learn which is which.\n>>\n>> Sure. It needs copyediting to make it readable standalone by not\n>> mentioning \"your misunderstanding\", inlining \"earlier Linus's suggestion\",\n>> etc., though.\n>>\n>> Patches welcome ;-)\n>\n> Okay, I'll send one later.\n\nThanks.\n"}]}