Hi Jan, On Fri, 11 Mar 2022, Jan Christoph Uhde wrote: > for the following commits: > > ``` git log > * 4fd94fd (HEAD -> master) 6 hours ago Jan Christoph Uhde Merge branch > 'b_two' > |\ > |* cc75466 6 hours ago Jan Christoph Uhde b_two > |/ > * 9ad8a2b 6 hours ago Jan Christoph Uhde Merge branch 'b_one' > |\ > |* b23658f (b_one) 6 hours ago Jan Christoph Uhde one > |/ > * a9d65bc 6 hours ago Jan Christoph Uhde initial commit > ``` > > I get a this merge script when rebasing onto the initial commit. > > ``` actual merge script > 1 label onto > 2 > 3 # Branch b-one > 4 reset onto > 5 pick b23658f one > 6 label b-one > 7 > 8 # Branch b-two > 9 reset onto > 10 merge -C 9ad8a2b b-one # Merge branch 'b_one' > 11 label branch-point > 12 pick cc75466 b_two > 13 label b-two > 14 > 15 reset branch-point # Merge branch 'b_one' > 16 merge -C 4fd94fd b-two # Merge branch 'b_two' > 17 > 18 # Rebase a9d65bc..4fd94fd onto a9d65bc (11 commands) > 19 # > ``` > > I think it should be more similar to this: > > > ``` suggested merge script > 1 label onto > 2 reset onto #Could imo go but probably avoids special cases > 3 > 4 # Branch b-one > 5 pick b23658f one > 6 label b-one > 7 reset onto > 8 merge -C 9ad8a2b b-one # Merge branch 'b_one' > 9 label branch-point > 10 > 11 # Branch b-two > 12 pick cc75466 b_two > 13 label b-two > 14 reset branch-point # Merge branch 'b_one' > 15 merge -C 4fd94fd b-two # Merge branch 'b_two' > 16 # add `label branch-point-1` here to avoid special cases?! > 17 > 18 # Rebase a9d65bc..4fd94fd onto a9d65bc (11 commands) > 19 # > ``` The idea of the current format is to facilitate moving branches around. Imagine, for example, that you wanted to change the order of b_one and b_two, or even base b_two directly on top of b_one instead of the merge commit, or base it on the same branch-point as b_one. With the `reset` command being a part of the topic branch's commands, it is pretty easy: you move the block starting with the comment and ending in the empty line, adjusting the `reset` command if necessary (or removing it). With the format you suggested, it would take substantially more mental energy to do the same. This is not a hypothetical use case, by the way. We frequently use it to clean up Git for Windows' branch thicket, usually when preparing the -rc0 versions. > Looking at the sequencer.c it might not be worth the invested time > to change the format. If it can not be resolved easily I think > removing the empty lines and the branch-comments would suffice > to reduce the confusion. I think they have been introduced to > help people but here they are a hindrance. > > Another unrelated suggestion is to start with `branch-point-0` > instead of `onto` and keep counting up. This would make the > edit-distances smaller when you fiddle with the first commits. It is often quite useful to see immediately which topics are branched off from `onto`. Take for example the `ready-for-upstream` sub-thicket of Git for Windows: https://github.com/git-for-windows/git/commit/7d77d55f1 This is the part of the quite complex set of Git for Windows patches which is deemed ready to be contributed to core Git. These contributions usually come in via PRs on top of Git for Windows' `main` and need to be moved further down, ideally directly on top of `onto` (which corresponds to the upstream Git tip commit). That way, they can be contributed as-are. However, while moving some of those patches down on top of `onto`, build/test failures occasionally indicate a dependency on another topic. Obviously, that other topic needs to be upstreamed first. The mental load of translating `branch-point-0` to mean "this is the new starting point" might not sound much, but juggling branch thickets is hard enough as it is, there is no need to make it harder. Ciao, Johannes
