Hi Junio, Kevin & Nikita, On Mon, 1 May 2017, Junio C Hamano wrote: > Nikita Orlov <fatemail@xxxxxxx> writes: > > >>On Sun, 30 Apr 2017, 1:56 +03:00 from Kevin Daudt <me@xxxxxxxxx>: > >>Not sure if this is the case here, but it at least confirms that rebase > >>--preserve-merges was not meant to reorder commits. > >> > >>See [this][1] thread for more background on this limitation. > >> > >>[0]: https://git-scm.com/docs/git-rebase#_bugs > >>[1]: https://public-inbox.org/git/1mtveu4.19lvgi1c0hmhaM%25lists@xxxxxxxxxxxxxxxx/ > > > > This is it. As I understand git-rebase--helper is an attempt to fix the bug. > > But it's still in development, isn't it? > > The impression I have been getting is that "rebase -p" was abandoned > by its author, and the recent rebase--helper work is solely for > re-implementing the performance sensitive part of "-i" (interactive). Indeed. The design of `-p` does not really allow for it to be fixed, as it overloads the meaning of `pick` to also "pick a merge commit". This further limits the usefulness of the `-p` feature by not allowing to adjust merge commits to merge anything else than the rebased commit^2 into anything else than the rebased commit^, which is kind of a realy big design bug. But then, I never meant for -p to be interactive, either, and others made it so. Therefore I refuse to take the blame for that. After my rebase-i-extra patch series (which Junio currently calls rebase-i-final) will be accepted, I plan to do a bit more work on the rebase -i front. One thing I have in mind is to implement a new --recreate-merges option. It will be closely modeled after the functionality of my Git garden shears [*1*] that I used to maintain Git for Windows' dozens of patch series on top of git.git's `maint` branch. Essentially, I want to introduce new commands (that are implemented as `exec` calls in the Git garden shears, with the noticeable performance implications on Windows) that - allow to mark the current commit with a label, - reset HEAD to a given label - merge a branch by a given label These commands would be new commands, and therefore backwards-compatible with the current command set. No need for special-casing `pick` in the case of the new mode. And then I would patch in the new --recreate-merges option simply by generating a todo list using those new commands. The todo list may look somewhat like this: mark onto # branch <my-cool-feature> pick deadbee5 lay some groundwork pick beeb0bab implement the cool feature pick deebadee document the cool feature mark my-cool-feature reset onto pick cabbadab fix a tyop remerge d00beedo my-cool-feature where `remerge <original-commit> <label>` would merge the commit with the given label using the commit message of the original merge commit. This would result in a history like this: ------------------------------------------ fix a tyop - Merge my-cool-feature \ / lay some groundwork - implement ... - document ... - If you have an idea for a better name than `remerge` (I do want to leave `merge` as command to create new merge commits that have not been there before), I'd like to hear your suggestion. Ciao, Johannes Footnote *1*: https://github.com/git-for-windows/build-extra/blob/master/shears.sh