{"thread":{"id":"57541","subject":"`git rebase -i --rebase-merges` formatting","startedAt":"2022-03-11T15:01:25Z","lastAt":"2022-03-24T14:23:50Z","messageCount":2,"participants":["Jan Christoph Uhde","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"451134","messageId":"9c494301-3c52-c953-95ab-48675634ada7@UhdeJc.com","threadId":"57541","inReplyTo":null,"subject":"`git rebase -i --rebase-merges` formatting","fromName":"Jan Christoph Uhde","fromEmail":"jan@uhdejc.com","sentAt":"2022-03-11T14:58:13Z","receivedAt":"2022-03-11T15:01:25Z","isPatch":false,"sender":{"key":"jan@uhdejc.com","avatar":null},"body":"Hello,\n\nfor the following commits:\n\n``` git log\n*   4fd94fd  (HEAD -> master) 6 hours ago Jan Christoph Uhde Merge branch 'b_two'\n|\\\n| * cc75466  6 hours ago Jan Christoph Uhde b_two\n|/\n*   9ad8a2b  6 hours ago Jan Christoph Uhde Merge branch 'b_one'\n|\\\n| * b23658f  (b_one) 6 hours ago Jan Christoph Uhde one\n|/\n* a9d65bc  6 hours ago Jan Christoph Uhde initial commit\n```\n\nI get a this merge script when rebasing onto the initial commit.\n\n``` actual merge script\n   1 label onto\n   2\n   3 # Branch b-one\n   4 reset onto\n   5 pick b23658f one\n   6 label b-one\n   7\n   8 # Branch b-two\n   9 reset onto\n  10 merge -C 9ad8a2b b-one # Merge branch 'b_one'\n  11 label branch-point\n  12 pick cc75466 b_two\n  13 label b-two\n  14\n  15 reset branch-point # Merge branch 'b_one'\n  16 merge -C 4fd94fd b-two # Merge branch 'b_two'\n  17\n  18 # Rebase a9d65bc..4fd94fd onto a9d65bc (11 commands)\n  19 #\n```\n\nI think it should be more similar to this:\n\n\n``` suggested merge script\n   1 label onto\n   2 reset onto #Could imo go but probably avoids special cases\n   3\n   4 # Branch b-one\n   5 pick b23658f one\n   6 label b-one\n   7 reset onto\n   8 merge -C 9ad8a2b b-one # Merge branch 'b_one'\n   9 label branch-point\n  10\n  11 # Branch b-two\n  12 pick cc75466 b_two\n  13 label b-two\n  14 reset branch-point # Merge branch 'b_one'\n  15 merge -C 4fd94fd b-two # Merge branch 'b_two'\n  16 # add `label branch-point-1` here to avoid special cases?!\n  17\n  18 # Rebase a9d65bc..4fd94fd onto a9d65bc (11 commands)\n  19 #\n```\n\n\nLooking at the sequencer.c it might not be worth the invested time\nto change the format. If it can not be resolved easily I think\nremoving the empty lines and the branch-comments would suffice\nto reduce the confusion. I think they have been introduced to\nhelp people but here they are a hindrance.\n\nAnother unrelated suggestion is to start with `branch-point-0`\ninstead of `onto` and keep counting up. This would make the\nedit-distances smaller when you fiddle with the first commits.\n\nRegards\n\nJan\n\n\n"},{"id":"452118","messageId":"nycvar.QRO.7.76.6.2203241505570.388@tvgsbejvaqbjf.bet","threadId":"57541","inReplyTo":"9c494301-3c52-c953-95ab-48675634ada7@UhdeJc.com","subject":"Re: `git rebase -i --rebase-merges` formatting","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-24T14:23:40Z","receivedAt":"2022-03-24T14:23:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jan,\n\nOn Fri, 11 Mar 2022, Jan Christoph Uhde wrote:\n\n> for the following commits:\n>\n> ``` git log\n> *   4fd94fd  (HEAD -> master) 6 hours ago Jan Christoph Uhde Merge branch\n> 'b_two'\n> |\\\n> |* cc75466  6 hours ago Jan Christoph Uhde b_two\n> |/\n> *   9ad8a2b  6 hours ago Jan Christoph Uhde Merge branch 'b_one'\n> |\\\n> |* b23658f  (b_one) 6 hours ago Jan Christoph Uhde one\n> |/\n> * a9d65bc  6 hours ago Jan Christoph Uhde initial commit\n> ```\n>\n> I get a this merge script when rebasing onto the initial commit.\n>\n> ``` actual merge script\n>   1 label onto\n>   2\n>   3 # Branch b-one\n>   4 reset onto\n>   5 pick b23658f one\n>   6 label b-one\n>   7\n>   8 # Branch b-two\n>   9 reset onto\n>  10 merge -C 9ad8a2b b-one # Merge branch 'b_one'\n>  11 label branch-point\n>  12 pick cc75466 b_two\n>  13 label b-two\n>  14\n>  15 reset branch-point # Merge branch 'b_one'\n>  16 merge -C 4fd94fd b-two # Merge branch 'b_two'\n>  17\n>  18 # Rebase a9d65bc..4fd94fd onto a9d65bc (11 commands)\n>  19 #\n> ```\n>\n> I think it should be more similar to this:\n>\n>\n> ``` suggested merge script\n>   1 label onto\n>   2 reset onto #Could imo go but probably avoids special cases\n>   3\n>   4 # Branch b-one\n>   5 pick b23658f one\n>   6 label b-one\n>   7 reset onto\n>   8 merge -C 9ad8a2b b-one # Merge branch 'b_one'\n>   9 label branch-point\n>  10\n>  11 # Branch b-two\n>  12 pick cc75466 b_two\n>  13 label b-two\n>  14 reset branch-point # Merge branch 'b_one'\n>  15 merge -C 4fd94fd b-two # Merge branch 'b_two'\n>  16 # add `label branch-point-1` here to avoid special cases?!\n>  17\n>  18 # Rebase a9d65bc..4fd94fd onto a9d65bc (11 commands)\n>  19 #\n> ```\n\nThe idea of the current format is to facilitate moving branches around.\nImagine, for example, that you wanted to change the order of b_one and\nb_two, or even base b_two directly on top of b_one instead of the merge\ncommit, or base it on the same branch-point as b_one.\n\nWith the `reset` command being a part of the topic branch's commands, it\nis pretty easy: you move the block starting with the comment and ending in\nthe empty line, adjusting the `reset` command if necessary (or removing\nit).\n\nWith the format you suggested, it would take substantially more mental\nenergy to do the same.\n\nThis is not a hypothetical use case, by the way. We frequently use it to\nclean up Git for Windows' branch thicket, usually when preparing the -rc0\nversions.\n\n> Looking at the sequencer.c it might not be worth the invested time\n> to change the format. If it can not be resolved easily I think\n> removing the empty lines and the branch-comments would suffice\n> to reduce the confusion. I think they have been introduced to\n> help people but here they are a hindrance.\n>\n> Another unrelated suggestion is to start with `branch-point-0`\n> instead of `onto` and keep counting up. This would make the\n> edit-distances smaller when you fiddle with the first commits.\n\nIt is often quite useful to see immediately which topics are branched off\nfrom `onto`.\n\nTake for example the `ready-for-upstream` sub-thicket of Git for Windows:\nhttps://github.com/git-for-windows/git/commit/7d77d55f1\n\nThis is the part of the quite complex set of Git for Windows patches which\nis deemed ready to be contributed to core Git. These contributions usually\ncome in via PRs on top of Git for Windows' `main` and need to be moved\nfurther down, ideally directly on top of `onto` (which corresponds to the\nupstream Git tip commit). That way, they can be contributed as-are.\n\nHowever, while moving some of those patches down on top of `onto`,\nbuild/test failures occasionally indicate a dependency on another topic.\nObviously, that other topic needs to be upstreamed first.\n\nThe mental load of translating `branch-point-0` to mean \"this is the new\nstarting point\" might not sound much, but juggling branch thickets is hard\nenough as it is, there is no need to make it harder.\n\nCiao,\nJohannes\n"}]}