{"thread":{"id":"52880","subject":"Inconsistancy with `git rebase --preserve-merges`","startedAt":"2020-02-24T14:10:19Z","lastAt":"2020-02-24T21:36:08Z","messageCount":3,"participants":["Robin Moussu","Kevin Daudt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"392405","messageId":"tmm3ViXf1QO5dCCNgDCHCHSZeUKUfiYvNoI9RMvdLlnOLk0oUt_w2SKgYu3LPh6no-wHhq1gXbVlBKgLcnGCR5HaTgWMx5se9KmJOKITUHk=@pm.me","threadId":"52880","inReplyTo":"v9k9hyJjfgQYYIczd9NqrjSdyOyxwqEB0iWyQ_TZCnobCZZoZ8_v6WB4KcWyW5xxRPdDUyEqEYfXylOnGI57CtK9KegMgp_0bz_5RrIIhHY=@pm.me","subject":"Inconsistancy with `git rebase --preserve-merges`","fromName":"Robin Moussu","fromEmail":"moussu.robin@pm.me","sentAt":"2020-02-24T14:10:07Z","receivedAt":"2020-02-24T14:10:19Z","isPatch":false,"sender":{"key":"moussu.robin@pm.me","avatar":"https://gravatar.com/avatar/e6f1710356a7fb672e1ee31e71b2ceafe4d788678de323436463ff3ae47a98fb?d=mp&s=160"},"body":"Hi. I noticed that the position of the `--preserve-merges` option of\n`git rebase` is significant (I think it shouldn't).\n\nThe following snippet doesn't preserve the merges:\n```\n$ git rebase --preserve-merges -i 412f07a~\npick 412f07a Work on dev branch\npick c6efccd Work on master branch\npick 71c8c37 Some work after the merge\n```\n\nWhereas this one does what I expect:\n```\n$ git rebase -i 412f07a~ --preserve-merges\npick 412f07a Work on dev branch\npick 616064c Merge branch 'master' into dev\npick 71c8c37 Some work after the merge\n```\n\nFor reference:\n```\n$ git log --graph --oneline\n* 71c8c37      (HEAD -> dev) Some work after the merge\n*   616064c    Merge branch 'master' into dev\n|\\\n| *   c6efccd  Work on master branch\n| *   ... (more work on master)\n* |   412f07a  Work on dev branch\n* |   ... (more work on dev)\n|/\n* 4ee50cb Common ancestor\n```\n\nStep to reproduce:\n```\nmkdir temp\ncd temp\ngit init\ngit commit --allow-empty -m 'Common ancestor'\ngit checkout -b dev\ngit commit --allow-empty -m 'Work on dev branch'\ngit tag some_commit\ngit checkout master\ngit commit --allow-empty -m 'Work on master branch'\ngit checkout dev\ngit merge master -m 'Merge branch 'master' into dev'\ngit commit --allow-empty -m 'Some work after the merge'\n```\nThen you will see that\n    git rebase -i some_commit --preserve-merges\nand\n    git rebase --preserve-merges  -i some_commit\ndon't have the same output.\n\nI am using git version 2.21.1 on Fedora 30.\n\nRobin.\n\n\n\n\n"},{"id":"392426","messageId":"20200224183648.GF1247035@alpha","threadId":"52880","inReplyTo":"tmm3ViXf1QO5dCCNgDCHCHSZeUKUfiYvNoI9RMvdLlnOLk0oUt_w2SKgYu3LPh6no-wHhq1gXbVlBKgLcnGCR5HaTgWMx5se9KmJOKITUHk=@pm.me","subject":"Re: Inconsistancy with `git rebase --preserve-merges`","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2020-02-24T18:36:48Z","receivedAt":"2020-02-24T18:36:51Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Mon, Feb 24, 2020 at 02:10:07PM +0000, Robin Moussu wrote:\n> Hi. I noticed that the position of the `--preserve-merges` option of\n> `git rebase` is significant (I think it shouldn't).\n> \n> The following snippet doesn't preserve the merges:\n> ```\n> $ git rebase --preserve-merges -i 412f07a~\n> pick 412f07a Work on dev branch\n> pick c6efccd Work on master branch\n> pick 71c8c37 Some work after the merge\n> ```\n> \n> Whereas this one does what I expect:\n> ```\n> $ git rebase -i 412f07a~ --preserve-merges\n> pick 412f07a Work on dev branch\n> pick 616064c Merge branch 'master' into dev\n> pick 71c8c37 Some work after the merge\n> ```\n> \n> For reference:\n> ```\n> $ git log --graph --oneline\n> * 71c8c37      (HEAD -> dev) Some work after the merge\n> *   616064c    Merge branch 'master' into dev\n> |\\\n> | *   c6efccd  Work on master branch\n> | *   ... (more work on master)\n> * |   412f07a  Work on dev branch\n> * |   ... (more work on dev)\n> |/\n> * 4ee50cb Common ancestor\n> ```\n> \n> Step to reproduce:\n> ```\n> mkdir temp\n> cd temp\n> git init\n> git commit --allow-empty -m 'Common ancestor'\n> git checkout -b dev\n> git commit --allow-empty -m 'Work on dev branch'\n> git tag some_commit\n> git checkout master\n> git commit --allow-empty -m 'Work on master branch'\n> git checkout dev\n> git merge master -m 'Merge branch 'master' into dev'\n> git commit --allow-empty -m 'Some work after the merge'\n> ```\n> Then you will see that\n>     git rebase -i some_commit --preserve-merges\n> and\n>     git rebase --preserve-merges  -i some_commit\n> don't have the same output.\n> \n> I am using git version 2.21.1 on Fedora 30.\n> \n> Robin.\n> \n\nCan you try `--rebase-merges` instead? Since v2.22.0 `--preseve-merges`\nis officially deprecated, but even before that it was already known to\nhave flaws.\n\nKevin\n"},{"id":"392443","messageId":"xmqqlforoegw.fsf@gitster-ct.c.googlers.com","threadId":"52880","inReplyTo":"20200224183648.GF1247035@alpha","subject":"Re: Inconsistancy with `git rebase --preserve-merges`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-02-24T21:35:59Z","receivedAt":"2020-02-24T21:36:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Daudt <me@ikke.info> writes:\n\n>> $ git rebase --preserve-merges -i 412f07a~\n>\n> Can you try `--rebase-merges` instead? Since v2.22.0 `--preseve-merges`\n> is officially deprecated, but even before that it was already known to\n> have flaws.\n\nThe options to \"rebase\" command seem to follow the usual \"last one\nwins\" pattern.  There is a single opts->type field, and upon seeing\n--preserve-merges, the field gets assigned REBASE_PRESERVE_MERGES,\nand then when the command line option parser sees \"-i\", the field\ngets overwritten by assigning REBASE_INTERACTIVE.  So\n\n    git rebase --preserve-merges -i 412f07a~\n    git rebase -i 412f07a~\n\nboth should do the same thing.\n\nI suspect that \"--rebase-merges -i\" may hide the real issue (which\nis \"the command line option parsing of rebase is messy\"), but it may\ndeserve to be cleaned up, now that the result of \"rewrite it in C\"\nefforts seems to have sufficiently stablized.\n\nWhat to clean-up?  There could be two-and-half ways to view it:\n\n * The options should follow the usual \"last one wins\" pattern; if\n   we take this stance, what happens with \"--rebase-merges -i\" is\n   buggy and \"--preserve-merges -i\" that behaves as a mere \"-i\" is\n   doing the right thing.  The part of the command line parser that\n   implements \"--rebase-merges\" should be fixed so that its effect\n   gets reverted when \"-i\" is seen later.\n\n * The options \"--rebase-merges\" and \"--perserve-merges\" (there may\n   be others) and \"--interactive\" should be mutually exclusive; if\n   we take this stance, we should error out when we see two or more\n   of them on the command line.\n\n * The options \"--rebase-merges\" and \"--preserve-merges\" (there may\n   be others) should be mutually exclusive or \"last one wins\", but\n   \"--interactive\" can be combined with them to make them\n   interactive.\n\nI am not sure which one is the best.  The impression I got from the\ncurrent state of the code is that it started from \"last one wins\",\nand the code wanted to transition to \"--interactive makes other\noptions go interactive\" but hasn't done a good job by leaving loose\nends (like what we saw with \"--preserve-merges\"), so perhaps the\nlast one is what we want to aim as a long term solution?  I dunno.\n\n"}]}