{"thread":{"id":"47565","subject":"rebase preserve-merges: incorrect merge commits","startedAt":"2018-01-08T10:25:13Z","lastAt":"2018-01-09T16:29:44Z","messageCount":11,"participants":["Matwey V. Kornilov","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"336125","messageId":"CAJs94Eas59UxZ+490AUSOuB37i+JBEvbCnGBMVpKi1G469OTbw@mail.gmail.com","threadId":"47565","inReplyTo":null,"subject":"rebase preserve-merges: incorrect merge commits","fromName":"Matwey V. Kornilov","fromEmail":"matwey.kornilov@gmail.com","sentAt":"2018-01-08T10:24:45Z","receivedAt":"2018-01-08T10:25:13Z","isPatch":false,"sender":{"key":"matwey.kornilov@gmail.com","avatar":"https://gravatar.com/avatar/721da1ce2e82dcb074f03f9d03683074ab4ad90f74d1bf3362b00283157d94aa?d=mp&s=160"},"body":"Hello,\n\nI think that rebase preserve-merges algorithm needs further\nimprovements. Probably, you already know it.\n\nI was playing with rebasing linux kernel tree and found that rebase\npreserve-merges works in counterintuitive way while handling\nmerge-commits. I don't want to discuss arising merge conflicts which\ncan be illuminated with help of rerere trained at original branch. An\nmajor issue here with silently auto-merging, some merge commits were\nsilently rebased with different content and it breaks the build :)\n\nI crafted toy example to demonstrate an issue:\nhttps://github.com/matwey/example-git-rebase-pm\nHere I have commit range v0.1..v0.2, then I return to v0.1 and\nintroduce new commit abc-0.1 with new file on v0.1. Then I want to\nrebase v0.1..v0.2 onto new abc-0.1. It is obvious that as soon as I\nintroduced single new file the difference between old v0.2 and new\nv0.2 should have only this new file. However it actually contains\nother changes.\n\nReproduce as the following:\n\ngit checkout v0.2\ngit branch abc-0.2\ngit checkout v0.1\ngit branch abc-0.1\ngit checkout abc-0.1\nvim LICENSE\ngit add LICENSE\ngit commit -a\ngit rebase --preserve-merges --onto abc-0.1 v0.1 abc-0.2\n\nActual result:\n\ndiff --git a/LICENSE b/LICENSE\ndeleted file mode 100644\nindex 297edb3..0000000\n--- a/LICENSE\n+++ /dev/null\n@@ -1,2 +0,0 @@\n-Hello, world!\n-\ndiff --git a/mod.c b/mod.c\nindex e6fa107..e339597 100644\n--- a/mod.c\n+++ b/mod.c\n@@ -2,5 +2,5 @@\n #include \"mod.h\"\n\n int mod_fun(char* buf, int len) {\n-       return -calc_fun(buf, len);\n+       return -calc_fun(buf, len, 0);\n }\n\nExpected result:\n\ndiff --git a/LICENSE b/LICENSE\ndeleted file mode 100644\nindex 297edb3..0000000\n--- a/LICENSE\n+++ /dev/null\n@@ -1,2 +0,0 @@\n-Hello, world!\n-\n\n\nAs far as I understand the root cause of this that when new merge\ncommit is created by rebase it is done simply by git merge\n$new_parents without taking into account any actual state of the\ninitial merge commit. This is why all manually introduced changes in\nmerge-commits are lost at rebase stage. I think that the following\nimprovement of merge-commit recreating stage would be possible:\n\n1) Let we have merge commit in the source tree\n\n-- A --\\\n        M--\n-- B --/\n\nAnd we want to rebase M to the new tree where new parents A' and B'\nalready existing.\n\n-- A'\n\n-- B'\n\n2) Then I suggest to perform it in three steps. First, lets take all\npossible differences between A and M, B and M and so on... and then\ntry to cherry-pick the diffs on A' and B' respectively. Here AM' and\nBM' are temporary commits which is very close in their states (in\nideal case, equal).\n\n-- A' -- (AM)'\n\n-- B' -- (BM)'\n\n3) Then we do git merge (AM)' (BM)' and ask user to resolve the\nconflicts if any. Here we obtain the following tree. Where M\" is\nproduced by git merge.\n\n-- A' -- (AM)' --\\\n                  M\"\n-- B' -- (BM)' --/\n\n4) Then we do merge between A' and B' but reset the state to be the\nsame as in M\" before new merge commit is created:\n\n-- A' -- (AM)' --\\\n     \\            \\\n       M' (==M\")    M\"\n     /            /\n-- B' -- (BM)' --/\n\n5) Then (AM)' (BM)' and M\" are discarded from the tree.\n\n\nProbably, I missed something important or incorrectly read\ngit-rebase--interactive.sh\n\n-- \nWith best regards,\nMatwey V. Kornilov\n"},{"id":"336142","messageId":"nycvar.QRO.7.76.6.1801081452290.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47565","inReplyTo":"CAJs94Eas59UxZ+490AUSOuB37i+JBEvbCnGBMVpKi1G469OTbw@mail.gmail.com","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-01-08T13:56:13Z","receivedAt":"2018-01-08T13:56:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matwey,\n\nOn Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n\n> I think that rebase preserve-merges algorithm needs further\n> improvements. Probably, you already know it.\n\nYes. preserve-merges is a fundamentally flawed design.\n\nPlease have a look here:\n\n\thttps://github.com/git/git/pull/447\n\nSince we are in a feature freeze in preparation for v2.16.0, I will\nsubmit these patch series shortly after v2.16.0 is released.\n\n> As far as I understand the root cause of this that when new merge\n> commit is created by rebase it is done simply by git merge\n> $new_parents without taking into account any actual state of the\n> initial merge commit.\n\nIndeed. preserve-merges does not allow commits to be reordered. (Actually,\nit *does* allow it, but then fails to handle it correctly.) We even have\ntest cases that mark this as \"known breakage\".\n\nBut really, I do not think it is worth trying to fix the broken design.\nBetter to go with the new recreate-merges. (I am biased, of course,\nbecause I invented recreate-merges. But then, I also invented\npreserve-merges, so ...)\n\nCiao,\nJohannes\n\n"},{"id":"336145","messageId":"CAJs94Ea52CcNvBxXVeZLvgsaS4YPiXaeDvRm2zUopoLVowgm+Q@mail.gmail.com","threadId":"47565","inReplyTo":"nycvar.QRO.7.76.6.1801081452290.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Matwey V. Kornilov","fromEmail":"matwey.kornilov@gmail.com","sentAt":"2018-01-08T14:42:29Z","receivedAt":"2018-01-08T14:42:55Z","isPatch":false,"sender":{"key":"matwey.kornilov@gmail.com","avatar":"https://gravatar.com/avatar/721da1ce2e82dcb074f03f9d03683074ab4ad90f74d1bf3362b00283157d94aa?d=mp&s=160"},"body":"2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> Hi Matwey,\n>\n> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>\n>> I think that rebase preserve-merges algorithm needs further\n>> improvements. Probably, you already know it.\n>\n> Yes. preserve-merges is a fundamentally flawed design.\n>\n> Please have a look here:\n>\n>         https://github.com/git/git/pull/447\n>\n> Since we are in a feature freeze in preparation for v2.16.0, I will\n> submit these patch series shortly after v2.16.0 is released.\n>\n>> As far as I understand the root cause of this that when new merge\n>> commit is created by rebase it is done simply by git merge\n>> $new_parents without taking into account any actual state of the\n>> initial merge commit.\n>\n> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n> it *does* allow it, but then fails to handle it correctly.) We even have\n> test cases that mark this as \"known breakage\".\n>\n> But really, I do not think it is worth trying to fix the broken design.\n> Better to go with the new recreate-merges. (I am biased, of course,\n> because I invented recreate-merges. But then, I also invented\n> preserve-merges, so ...)\n\nWell. I just checked --recreate-merges=no-rebase-cousins from the PR\nand found that it produces the same wrong result in my test example.\nThe topology is reproduced correctly, but merge-commit content is\nbroken.\nI did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n\n>\n> Ciao,\n> Johannes\n>\n\n\n\n-- \nWith best regards,\nMatwey V. Kornilov\n"},{"id":"336147","messageId":"CAJs94Ea_Kf5RFMuPreBOGYEjhECdQP2F7m=-wDkf9xRnQFPfhA@mail.gmail.com","threadId":"47565","inReplyTo":"CAJs94Ea52CcNvBxXVeZLvgsaS4YPiXaeDvRm2zUopoLVowgm+Q@mail.gmail.com","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Matwey V. Kornilov","fromEmail":"matwey.kornilov@gmail.com","sentAt":"2018-01-08T14:46:09Z","receivedAt":"2018-01-08T14:46:36Z","isPatch":false,"sender":{"key":"matwey.kornilov@gmail.com","avatar":"https://gravatar.com/avatar/721da1ce2e82dcb074f03f9d03683074ab4ad90f74d1bf3362b00283157d94aa?d=mp&s=160"},"body":"2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n> 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> Hi Matwey,\n>>\n>> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>>\n>>> I think that rebase preserve-merges algorithm needs further\n>>> improvements. Probably, you already know it.\n>>\n>> Yes. preserve-merges is a fundamentally flawed design.\n>>\n>> Please have a look here:\n>>\n>>         https://github.com/git/git/pull/447\n>>\n>> Since we are in a feature freeze in preparation for v2.16.0, I will\n>> submit these patch series shortly after v2.16.0 is released.\n>>\n>>> As far as I understand the root cause of this that when new merge\n>>> commit is created by rebase it is done simply by git merge\n>>> $new_parents without taking into account any actual state of the\n>>> initial merge commit.\n>>\n>> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n>> it *does* allow it, but then fails to handle it correctly.) We even have\n>> test cases that mark this as \"known breakage\".\n>>\n>> But really, I do not think it is worth trying to fix the broken design.\n>> Better to go with the new recreate-merges. (I am biased, of course,\n>> because I invented recreate-merges. But then, I also invented\n>> preserve-merges, so ...)\n>\n> Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n> and found that it produces the same wrong result in my test example.\n> The topology is reproduced correctly, but merge-commit content is\n> broken.\n> I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n\nIndeed, exactly as you still say in the documentation: \"Merge conflict\nresolutions or manual amendments to merge commits are not preserved.\"\nMy initial point is that they have to be preserved. Probably in\nrecreate-merges, if preserve-merges is discontinued.\n\n>\n>>\n>> Ciao,\n>> Johannes\n>>\n>\n>\n>\n> --\n> With best regards,\n> Matwey V. Kornilov\n\n\n\n-- \nWith best regards,\nMatwey V. Kornilov\n"},{"id":"336154","messageId":"nycvar.QRO.7.76.6.1801081730170.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47565","inReplyTo":"CAJs94Ea_Kf5RFMuPreBOGYEjhECdQP2F7m=-wDkf9xRnQFPfhA@mail.gmail.com","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-01-08T16:32:57Z","receivedAt":"2018-01-08T16:33:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n\n> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> Hi Matwey,\n> >>\n> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >>\n> >>> I think that rebase preserve-merges algorithm needs further\n> >>> improvements. Probably, you already know it.\n> >>\n> >> Yes. preserve-merges is a fundamentally flawed design.\n> >>\n> >> Please have a look here:\n> >>\n> >>         https://github.com/git/git/pull/447\n> >>\n> >> Since we are in a feature freeze in preparation for v2.16.0, I will\n> >> submit these patch series shortly after v2.16.0 is released.\n> >>\n> >>> As far as I understand the root cause of this that when new merge\n> >>> commit is created by rebase it is done simply by git merge\n> >>> $new_parents without taking into account any actual state of the\n> >>> initial merge commit.\n> >>\n> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n> >> it *does* allow it, but then fails to handle it correctly.) We even have\n> >> test cases that mark this as \"known breakage\".\n> >>\n> >> But really, I do not think it is worth trying to fix the broken design.\n> >> Better to go with the new recreate-merges. (I am biased, of course,\n> >> because I invented recreate-merges. But then, I also invented\n> >> preserve-merges, so ...)\n> >\n> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n> > and found that it produces the same wrong result in my test example.\n> > The topology is reproduced correctly, but merge-commit content is\n> > broken.\n> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n> \n> Indeed, exactly as you still say in the documentation: \"Merge conflict\n> resolutions or manual amendments to merge commits are not preserved.\"\n> My initial point is that they have to be preserved. Probably in\n> recreate-merges, if preserve-merges is discontinued.\n\nAh, but that is consistent with how non-merge-preserving rebase works: the\n`pick` commands *also* do not record merge conflict resolution...\n\nCiao,\nJohannes\n"},{"id":"336157","messageId":"CAJs94EYrBgNW-bzoEgy9=fStJW2esoULxfOHX45V63HavqOCpw@mail.gmail.com","threadId":"47565","inReplyTo":"nycvar.QRO.7.76.6.1801081730170.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Matwey V. Kornilov","fromEmail":"matwey.kornilov@gmail.com","sentAt":"2018-01-08T17:24:05Z","receivedAt":"2018-01-08T17:24:32Z","isPatch":false,"sender":{"key":"matwey.kornilov@gmail.com","avatar":"https://gravatar.com/avatar/721da1ce2e82dcb074f03f9d03683074ab4ad90f74d1bf3362b00283157d94aa?d=mp&s=160"},"body":"2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> Hi,\n>\n> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>\n>> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n>> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> >> Hi Matwey,\n>> >>\n>> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>> >>\n>> >>> I think that rebase preserve-merges algorithm needs further\n>> >>> improvements. Probably, you already know it.\n>> >>\n>> >> Yes. preserve-merges is a fundamentally flawed design.\n>> >>\n>> >> Please have a look here:\n>> >>\n>> >>         https://github.com/git/git/pull/447\n>> >>\n>> >> Since we are in a feature freeze in preparation for v2.16.0, I will\n>> >> submit these patch series shortly after v2.16.0 is released.\n>> >>\n>> >>> As far as I understand the root cause of this that when new merge\n>> >>> commit is created by rebase it is done simply by git merge\n>> >>> $new_parents without taking into account any actual state of the\n>> >>> initial merge commit.\n>> >>\n>> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n>> >> it *does* allow it, but then fails to handle it correctly.) We even have\n>> >> test cases that mark this as \"known breakage\".\n>> >>\n>> >> But really, I do not think it is worth trying to fix the broken design.\n>> >> Better to go with the new recreate-merges. (I am biased, of course,\n>> >> because I invented recreate-merges. But then, I also invented\n>> >> preserve-merges, so ...)\n>> >\n>> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n>> > and found that it produces the same wrong result in my test example.\n>> > The topology is reproduced correctly, but merge-commit content is\n>> > broken.\n>> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n>>\n>> Indeed, exactly as you still say in the documentation: \"Merge conflict\n>> resolutions or manual amendments to merge commits are not preserved.\"\n>> My initial point is that they have to be preserved. Probably in\n>> recreate-merges, if preserve-merges is discontinued.\n>\n> Ah, but that is consistent with how non-merge-preserving rebase works: the\n> `pick` commands *also* do not record merge conflict resolution...\n>\n\nI am sorry, didn't get it. When I do non-merge-preserving rebase\n--interactive there is no way to `pick' merge-commit at all.\n\n> Ciao,\n> Johannes\n\n\n\n-- \nWith best regards,\nMatwey V. Kornilov\n"},{"id":"336177","messageId":"nycvar.QRO.7.76.6.1801082034470.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47565","inReplyTo":"CAJs94EYrBgNW-bzoEgy9=fStJW2esoULxfOHX45V63HavqOCpw@mail.gmail.com","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-01-08T19:36:10Z","receivedAt":"2018-01-08T19:36:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matwey,\n\nOn Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n\n> 2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >\n> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >\n> >> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n> >> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> >> Hi Matwey,\n> >> >>\n> >> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >> >>\n> >> >>> I think that rebase preserve-merges algorithm needs further\n> >> >>> improvements. Probably, you already know it.\n> >> >>\n> >> >> Yes. preserve-merges is a fundamentally flawed design.\n> >> >>\n> >> >> Please have a look here:\n> >> >>\n> >> >>         https://github.com/git/git/pull/447\n> >> >>\n> >> >> Since we are in a feature freeze in preparation for v2.16.0, I will\n> >> >> submit these patch series shortly after v2.16.0 is released.\n> >> >>\n> >> >>> As far as I understand the root cause of this that when new merge\n> >> >>> commit is created by rebase it is done simply by git merge\n> >> >>> $new_parents without taking into account any actual state of the\n> >> >>> initial merge commit.\n> >> >>\n> >> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n> >> >> it *does* allow it, but then fails to handle it correctly.) We even have\n> >> >> test cases that mark this as \"known breakage\".\n> >> >>\n> >> >> But really, I do not think it is worth trying to fix the broken design.\n> >> >> Better to go with the new recreate-merges. (I am biased, of course,\n> >> >> because I invented recreate-merges. But then, I also invented\n> >> >> preserve-merges, so ...)\n> >> >\n> >> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n> >> > and found that it produces the same wrong result in my test example.\n> >> > The topology is reproduced correctly, but merge-commit content is\n> >> > broken.\n> >> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n> >>\n> >> Indeed, exactly as you still say in the documentation: \"Merge conflict\n> >> resolutions or manual amendments to merge commits are not preserved.\"\n> >> My initial point is that they have to be preserved. Probably in\n> >> recreate-merges, if preserve-merges is discontinued.\n> >\n> > Ah, but that is consistent with how non-merge-preserving rebase works: the\n> > `pick` commands *also* do not record merge conflict resolution...\n> >\n> \n> I am sorry, didn't get it. When I do non-merge-preserving rebase\n> --interactive there is no way to `pick' merge-commit at all.\n\nRight, but you can `pick` commits and you can get merge conflicts. And you\nneed to resolve those merge conflicts and those merge conflict resolutions\nare not preserved for future interactive rebases, unless you use `rerere`\n(in which case it also extends to `pick`ing merge commits in\nmerge-preserving mode).\n\nCiao,\nJohannes\n"},{"id":"336225","messageId":"CAJs94Eb0Yf=4Obk6BpifSZaPiw3ArY-01LbTb1nUaM+o2hSayw@mail.gmail.com","threadId":"47565","inReplyTo":"nycvar.QRO.7.76.6.1801082034470.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Matwey V. Kornilov","fromEmail":"matwey.kornilov@gmail.com","sentAt":"2018-01-09T09:49:50Z","receivedAt":"2018-01-09T09:50:19Z","isPatch":false,"sender":{"key":"matwey.kornilov@gmail.com","avatar":"https://gravatar.com/avatar/721da1ce2e82dcb074f03f9d03683074ab4ad90f74d1bf3362b00283157d94aa?d=mp&s=160"},"body":"2018-01-08 22:36 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> Hi Matwey,\n>\n> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>\n>> 2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> >\n>> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>> >\n>> >> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n>> >> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> >> >> Hi Matwey,\n>> >> >>\n>> >> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>> >> >>\n>> >> >>> I think that rebase preserve-merges algorithm needs further\n>> >> >>> improvements. Probably, you already know it.\n>> >> >>\n>> >> >> Yes. preserve-merges is a fundamentally flawed design.\n>> >> >>\n>> >> >> Please have a look here:\n>> >> >>\n>> >> >>         https://github.com/git/git/pull/447\n>> >> >>\n>> >> >> Since we are in a feature freeze in preparation for v2.16.0, I will\n>> >> >> submit these patch series shortly after v2.16.0 is released.\n>> >> >>\n>> >> >>> As far as I understand the root cause of this that when new merge\n>> >> >>> commit is created by rebase it is done simply by git merge\n>> >> >>> $new_parents without taking into account any actual state of the\n>> >> >>> initial merge commit.\n>> >> >>\n>> >> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n>> >> >> it *does* allow it, but then fails to handle it correctly.) We even have\n>> >> >> test cases that mark this as \"known breakage\".\n>> >> >>\n>> >> >> But really, I do not think it is worth trying to fix the broken design.\n>> >> >> Better to go with the new recreate-merges. (I am biased, of course,\n>> >> >> because I invented recreate-merges. But then, I also invented\n>> >> >> preserve-merges, so ...)\n>> >> >\n>> >> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n>> >> > and found that it produces the same wrong result in my test example.\n>> >> > The topology is reproduced correctly, but merge-commit content is\n>> >> > broken.\n>> >> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n>> >>\n>> >> Indeed, exactly as you still say in the documentation: \"Merge conflict\n>> >> resolutions or manual amendments to merge commits are not preserved.\"\n>> >> My initial point is that they have to be preserved. Probably in\n>> >> recreate-merges, if preserve-merges is discontinued.\n>> >\n>> > Ah, but that is consistent with how non-merge-preserving rebase works: the\n>> > `pick` commands *also* do not record merge conflict resolution...\n>> >\n>>\n>> I am sorry, didn't get it. When I do non-merge-preserving rebase\n>> --interactive there is no way to `pick' merge-commit at all.\n>\n> Right, but you can `pick` commits and you can get merge conflicts. And you\n> need to resolve those merge conflicts and those merge conflict resolutions\n> are not preserved for future interactive rebases, unless you use `rerere`\n> (in which case it also extends to `pick`ing merge commits in\n> merge-preserving mode).\n\nAre you talking about merge conflicts arising due to commits reordering?\n\n>\n> Ciao,\n> Johannes\n\n\n\n-- \nWith best regards,\nMatwey V. Kornilov\n"},{"id":"336251","messageId":"nycvar.QRO.7.76.6.1801091424170.37@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47565","inReplyTo":"CAJs94Eb0Yf=4Obk6BpifSZaPiw3ArY-01LbTb1nUaM+o2hSayw@mail.gmail.com","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-01-09T13:25:39Z","receivedAt":"2018-01-09T13:25:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matwey,\n\nOn Tue, 9 Jan 2018, Matwey V. Kornilov wrote:\n\n> 2018-01-08 22:36 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >\n> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >\n> >> 2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> >\n> >> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >> >\n> >> >> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n> >> >> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> >> >> Hi Matwey,\n> >> >> >>\n> >> >> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >> >> >>\n> >> >> >>> I think that rebase preserve-merges algorithm needs further\n> >> >> >>> improvements. Probably, you already know it.\n> >> >> >>\n> >> >> >> Yes. preserve-merges is a fundamentally flawed design.\n> >> >> >>\n> >> >> >> Please have a look here:\n> >> >> >>\n> >> >> >>         https://github.com/git/git/pull/447\n> >> >> >>\n> >> >> >> Since we are in a feature freeze in preparation for v2.16.0, I will\n> >> >> >> submit these patch series shortly after v2.16.0 is released.\n> >> >> >>\n> >> >> >>> As far as I understand the root cause of this that when new merge\n> >> >> >>> commit is created by rebase it is done simply by git merge\n> >> >> >>> $new_parents without taking into account any actual state of the\n> >> >> >>> initial merge commit.\n> >> >> >>\n> >> >> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n> >> >> >> it *does* allow it, but then fails to handle it correctly.) We even have\n> >> >> >> test cases that mark this as \"known breakage\".\n> >> >> >>\n> >> >> >> But really, I do not think it is worth trying to fix the broken design.\n> >> >> >> Better to go with the new recreate-merges. (I am biased, of course,\n> >> >> >> because I invented recreate-merges. But then, I also invented\n> >> >> >> preserve-merges, so ...)\n> >> >> >\n> >> >> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n> >> >> > and found that it produces the same wrong result in my test example.\n> >> >> > The topology is reproduced correctly, but merge-commit content is\n> >> >> > broken.\n> >> >> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n> >> >>\n> >> >> Indeed, exactly as you still say in the documentation: \"Merge conflict\n> >> >> resolutions or manual amendments to merge commits are not preserved.\"\n> >> >> My initial point is that they have to be preserved. Probably in\n> >> >> recreate-merges, if preserve-merges is discontinued.\n> >> >\n> >> > Ah, but that is consistent with how non-merge-preserving rebase works: the\n> >> > `pick` commands *also* do not record merge conflict resolution...\n> >> >\n> >>\n> >> I am sorry, didn't get it. When I do non-merge-preserving rebase\n> >> --interactive there is no way to `pick' merge-commit at all.\n> >\n> > Right, but you can `pick` commits and you can get merge conflicts. And you\n> > need to resolve those merge conflicts and those merge conflict resolutions\n> > are not preserved for future interactive rebases, unless you use `rerere`\n> > (in which case it also extends to `pick`ing merge commits in\n> > merge-preserving mode).\n> \n> Are you talking about merge conflicts arising due to commits reordering?\n\nMerge conflicts can arise from commit reordering, and they can also arise\nfrom commits introduced in \"upstream\" in the meantime.\n\nCiao,\nJohannes\n"},{"id":"336252","messageId":"CAJs94EaKObUhvNedMmOGWA9SDMH7y-2V7DLkxO=MabddpbjYFQ@mail.gmail.com","threadId":"47565","inReplyTo":"nycvar.QRO.7.76.6.1801091424170.37@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Matwey V. Kornilov","fromEmail":"matwey.kornilov@gmail.com","sentAt":"2018-01-09T14:19:05Z","receivedAt":"2018-01-09T14:19:33Z","isPatch":false,"sender":{"key":"matwey.kornilov@gmail.com","avatar":"https://gravatar.com/avatar/721da1ce2e82dcb074f03f9d03683074ab4ad90f74d1bf3362b00283157d94aa?d=mp&s=160"},"body":"2018-01-09 16:25 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> Hi Matwey,\n>\n> On Tue, 9 Jan 2018, Matwey V. Kornilov wrote:\n>\n>> 2018-01-08 22:36 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> >\n>> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>> >\n>> >> 2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> >> >\n>> >> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>> >> >\n>> >> >> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n>> >> >> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n>> >> >> >> Hi Matwey,\n>> >> >> >>\n>> >> >> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n>> >> >> >>\n>> >> >> >>> I think that rebase preserve-merges algorithm needs further\n>> >> >> >>> improvements. Probably, you already know it.\n>> >> >> >>\n>> >> >> >> Yes. preserve-merges is a fundamentally flawed design.\n>> >> >> >>\n>> >> >> >> Please have a look here:\n>> >> >> >>\n>> >> >> >>         https://github.com/git/git/pull/447\n>> >> >> >>\n>> >> >> >> Since we are in a feature freeze in preparation for v2.16.0, I will\n>> >> >> >> submit these patch series shortly after v2.16.0 is released.\n>> >> >> >>\n>> >> >> >>> As far as I understand the root cause of this that when new merge\n>> >> >> >>> commit is created by rebase it is done simply by git merge\n>> >> >> >>> $new_parents without taking into account any actual state of the\n>> >> >> >>> initial merge commit.\n>> >> >> >>\n>> >> >> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n>> >> >> >> it *does* allow it, but then fails to handle it correctly.) We even have\n>> >> >> >> test cases that mark this as \"known breakage\".\n>> >> >> >>\n>> >> >> >> But really, I do not think it is worth trying to fix the broken design.\n>> >> >> >> Better to go with the new recreate-merges. (I am biased, of course,\n>> >> >> >> because I invented recreate-merges. But then, I also invented\n>> >> >> >> preserve-merges, so ...)\n>> >> >> >\n>> >> >> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n>> >> >> > and found that it produces the same wrong result in my test example.\n>> >> >> > The topology is reproduced correctly, but merge-commit content is\n>> >> >> > broken.\n>> >> >> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n>> >> >>\n>> >> >> Indeed, exactly as you still say in the documentation: \"Merge conflict\n>> >> >> resolutions or manual amendments to merge commits are not preserved.\"\n>> >> >> My initial point is that they have to be preserved. Probably in\n>> >> >> recreate-merges, if preserve-merges is discontinued.\n>> >> >\n>> >> > Ah, but that is consistent with how non-merge-preserving rebase works: the\n>> >> > `pick` commands *also* do not record merge conflict resolution...\n>> >> >\n>> >>\n>> >> I am sorry, didn't get it. When I do non-merge-preserving rebase\n>> >> --interactive there is no way to `pick' merge-commit at all.\n>> >\n>> > Right, but you can `pick` commits and you can get merge conflicts. And you\n>> > need to resolve those merge conflicts and those merge conflict resolutions\n>> > are not preserved for future interactive rebases, unless you use `rerere`\n>> > (in which case it also extends to `pick`ing merge commits in\n>> > merge-preserving mode).\n>>\n>> Are you talking about merge conflicts arising due to commits reordering?\n>\n> Merge conflicts can arise from commit reordering, and they can also arise\n> from commits introduced in \"upstream\" in the meantime.\n\nThen I am totally agree with you.\nBut initially I said about conflict resolutions and amendments already\ncontained in existing merge-commits. While rerere can at least learn\nconflict resolutions from existing merge-commits, rerere cannot learn\nand recover manual amendments.\n\n>\n> Ciao,\n> Johannes\n\n\n\n-- \nWith best regards,\nMatwey V. Kornilov\n"},{"id":"336265","messageId":"nycvar.QRO.7.76.6.1801091728590.37@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47565","inReplyTo":"CAJs94EaKObUhvNedMmOGWA9SDMH7y-2V7DLkxO=MabddpbjYFQ@mail.gmail.com","subject":"Re: rebase preserve-merges: incorrect merge commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-01-09T16:29:18Z","receivedAt":"2018-01-09T16:29:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matwey,\n\nOn Tue, 9 Jan 2018, Matwey V. Kornilov wrote:\n\n> 2018-01-09 16:25 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> > Hi Matwey,\n> >\n> > On Tue, 9 Jan 2018, Matwey V. Kornilov wrote:\n> >\n> >> 2018-01-08 22:36 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> >\n> >> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >> >\n> >> >> 2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> >> >\n> >> >> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >> >> >\n> >> >> >> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:\n> >> >> >> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> >> >> >> >> Hi Matwey,\n> >> >> >> >>\n> >> >> >> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:\n> >> >> >> >>\n> >> >> >> >>> I think that rebase preserve-merges algorithm needs further\n> >> >> >> >>> improvements. Probably, you already know it.\n> >> >> >> >>\n> >> >> >> >> Yes. preserve-merges is a fundamentally flawed design.\n> >> >> >> >>\n> >> >> >> >> Please have a look here:\n> >> >> >> >>\n> >> >> >> >>         https://github.com/git/git/pull/447\n> >> >> >> >>\n> >> >> >> >> Since we are in a feature freeze in preparation for v2.16.0, I will\n> >> >> >> >> submit these patch series shortly after v2.16.0 is released.\n> >> >> >> >>\n> >> >> >> >>> As far as I understand the root cause of this that when new merge\n> >> >> >> >>> commit is created by rebase it is done simply by git merge\n> >> >> >> >>> $new_parents without taking into account any actual state of the\n> >> >> >> >>> initial merge commit.\n> >> >> >> >>\n> >> >> >> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually,\n> >> >> >> >> it *does* allow it, but then fails to handle it correctly.) We even have\n> >> >> >> >> test cases that mark this as \"known breakage\".\n> >> >> >> >>\n> >> >> >> >> But really, I do not think it is worth trying to fix the broken design.\n> >> >> >> >> Better to go with the new recreate-merges. (I am biased, of course,\n> >> >> >> >> because I invented recreate-merges. But then, I also invented\n> >> >> >> >> preserve-merges, so ...)\n> >> >> >> >\n> >> >> >> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR\n> >> >> >> > and found that it produces the same wrong result in my test example.\n> >> >> >> > The topology is reproduced correctly, but merge-commit content is\n> >> >> >> > broken.\n> >> >> >> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2\n> >> >> >>\n> >> >> >> Indeed, exactly as you still say in the documentation: \"Merge conflict\n> >> >> >> resolutions or manual amendments to merge commits are not preserved.\"\n> >> >> >> My initial point is that they have to be preserved. Probably in\n> >> >> >> recreate-merges, if preserve-merges is discontinued.\n> >> >> >\n> >> >> > Ah, but that is consistent with how non-merge-preserving rebase works: the\n> >> >> > `pick` commands *also* do not record merge conflict resolution...\n> >> >> >\n> >> >>\n> >> >> I am sorry, didn't get it. When I do non-merge-preserving rebase\n> >> >> --interactive there is no way to `pick' merge-commit at all.\n> >> >\n> >> > Right, but you can `pick` commits and you can get merge conflicts. And you\n> >> > need to resolve those merge conflicts and those merge conflict resolutions\n> >> > are not preserved for future interactive rebases, unless you use `rerere`\n> >> > (in which case it also extends to `pick`ing merge commits in\n> >> > merge-preserving mode).\n> >>\n> >> Are you talking about merge conflicts arising due to commits reordering?\n> >\n> > Merge conflicts can arise from commit reordering, and they can also arise\n> > from commits introduced in \"upstream\" in the meantime.\n> \n> Then I am totally agree with you.\n> But initially I said about conflict resolutions and amendments already\n> contained in existing merge-commits. While rerere can at least learn\n> conflict resolutions from existing merge-commits, rerere cannot learn\n> and recover manual amendments.\n\nGreat, so the information is all there and you can implement it? :-)\n\nCiao,\nJohannes\n"}]}