{"thread":{"id":"61676","subject":"Regarding howto/revert-a-faulty-merge.txt - another way to revert a merge","startedAt":"2024-06-24T10:17:37Z","lastAt":"2024-06-26T12:18:06Z","messageCount":3,"participants":["Noam Yorav-Raphael","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"497559","messageId":"CAO8o=D5womGcsVsGT4h2=3qry05mMrd9dFDkZHrLtPCDw0+2Tg@mail.gmail.com","threadId":"61676","inReplyTo":null,"subject":"Regarding howto/revert-a-faulty-merge.txt - another way to revert a merge","fromName":"Noam Yorav-Raphael","fromEmail":"noamraph@gmail.com","sentAt":"2024-06-24T10:17:25Z","receivedAt":"2024-06-24T10:17:37Z","isPatch":false,"sender":{"key":"noamraph@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1553464?v=4"},"body":"Hi,\n\nI was looking for a way to revert a merge, and found the document at\nhowto/revert-a-faulty-merge.txt. It basically suggests that if you\nreverted a merge and want to re-merge, you should first revert the\nrevert.\n\nThis is fine, but it means that you must remember to revert the revert\nbefore the next merge, which may be hard to remember. I thought of\nanother solution: In the source branch, add a commit reverting all the\nchanges since the previous merge, then merge again from that brange to\nthe master branch, and then revert the revert. In a diagram:\n\n----o---o---o---M---o---o------------W-------\n / / /\n------o---A---B---C-------!C!B!A---o----ABC--\n\n(`!C!B!A` means a commit that reverts C, B and A, returning to `o`.\n`ABC` means a commit that applies A, B and C, thus returning to the\ntree after C.)\n\nNow the W commit really reverts the M commit, and you can forget about it.\n\nWould you be interested in a patch adding this to\nhowto/revert-a-faulty-merge.txt?\n\nThanks,\nNoam\n"},{"id":"497609","messageId":"xmqqo77p8kct.fsf@gitster.g","threadId":"61676","inReplyTo":"CAO8o=D5womGcsVsGT4h2=3qry05mMrd9dFDkZHrLtPCDw0+2Tg@mail.gmail.com","subject":"Re: Regarding howto/revert-a-faulty-merge.txt - another way to revert a merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-25T09:03:46Z","receivedAt":"2024-06-25T09:03:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Noam Yorav-Raphael writes:\n\n> This is fine, but it means that you must remember to revert the revert\n> before the next merge, which may be hard to remember. I thought of\n> another solution: In the source branch, add a commit reverting all the\n> changes since the previous merge, then merge again from that brange to\n> the master branch, and then revert the revert. In a diagram:\n>\n> ----o---o---o---M---o---o------------W-------\n> / / /\n> ------o---A---B---C-------!C!B!A---o----ABC--\n>\n> (`!C!B!A` means a commit that reverts C, B and A, returning to `o`.\n> `ABC` means a commit that applies A, B and C, thus returning to the\n> tree after C.)\n\nThese, we definitely do not want them [*].\n\n> Now the W commit really reverts the M commit, and you can forget about it.\n>\n> Would you be interested in a patch adding this to\n> howto/revert-a-faulty-merge.txt?\n\nWhat you have above is a moral equivalent to the \"On the other hand\"\nsenario. In the picture in the existing document, the new\nincarnation of A'-B'-C' chain folks from the commit after W, but it\ndoes not have to (it could even be a fork from the original A^).\nIOW, there is no need for the A'-B'-C' chain to be strict descendant\nof the original C like the above picture.\n\nWhat happens in practice (and I do this myself sometimes when I have\nto revert out a topic out of 'next') is\n\n * Revert W of a merge M is made.\n\n * At the very same time, the original A--B--C chain is discarded,\n and the topic is rebased on some appropriate base (e.g. the\n parent of original A in your picture, for example, or the commit\n after W in the \"On the other hand\" part of the exicting document,\n exact base chosen does not matter all that much) to create an\n updated A'--B'--C' commits. While this chain is being polished\n (without getting merged into the integration branch to become a\n descendant of W), you may rebase them again and again until they\n are polished enough. And then you merge the result, which will\n lead to \"If you reverted the revert in such a case\" topology in\n the existing document.\n\nSo if you want to avoid \"we can forget that we have reverted\"\nproblem, not reverting the revert, but rebuilding the entire chain,\nis a better approach that gives you cleanest history to work with,\nand that is what we already offer as an alternative of \"reverting a\nrevert\", not \"squashed revert and squashed reapply on the side\nbranch\".\n\nSo, I dunno if we want to add yet another one.\n\n\n[Footnote]\n\n * We do not want the squashed CBA!!! revert or ABC reapply, both of\n which are large balls of wax that interferes with bisectability.\n"},{"id":"497683","messageId":"CAO8o=D5T8geKY98ep6YX+Pa-HVLNXtWznEFxEjTkW3Z+JCxJ_w@mail.gmail.com","threadId":"61676","inReplyTo":"xmqqo77p8kct.fsf@gitster.g","subject":"Re: Regarding howto/revert-a-faulty-merge.txt - another way to revert a merge","fromName":"Noam Yorav-Raphael","fromEmail":"noamraph@gmail.com","sentAt":"2024-06-26T12:17:54Z","receivedAt":"2024-06-26T12:18:06Z","isPatch":false,"sender":{"key":"noamraph@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1553464?v=4"},"body":"On Tue, Jun 25, 2024 at 12:03 PM Junio C Hamano wrote:\n>\n> These, we definitely do not want them [*].\n> * We do not want the squashed CBA!!! revert or ABC reapply, both of\n> which are large balls of wax that interferes with bisectability.\n\n> So if you want to avoid \"we can forget that we have reverted\"\n> problem, not reverting the revert, but rebuilding the entire chain,\n> is a better approach that gives you cleanest history to work with,\n> and that is what we already offer as an alternative of \"reverting a\n> revert\", not \"squashed revert and squashed reapply on the side\n> branch\".\n\nIf you don't mind rebasing the branch, what you're suggesting is fine.\nHowever, if it's a long-running branch, with multiple people working\non it, rebasing is not an option. In that case, I think that my\nsuggestion makes a lot of sense. A good idea would be to add the\n\"large balls of wax\" commits to a `.git-blame-ignore-revs` (or\nwhatever you choose to call it) file.\n\nCheers,\nNoam\n"}]}