`git rebase -i --rebase-merges` formatting

`git rebase -i --rebase-merges` formatting

[Jan Christoph Uhde]

Hello,

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 #
```


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.

Regards

Jan

Re: `git rebase -i --rebase-merges` formatting

[Johannes Schindelin]

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