Hi Junio,

On Wed, 25 Apr 2018, Junio C Hamano wrote:

* js/rebase-recreate-merge (2018-04-24) 16 commits
 - rebase -i --rebase-merges: add a section to the man page
 - rebase -i: introduce --rebase-merges=[no-]rebase-cousins
 - pull: accept --rebase=merges to recreate the branch topology
 - rebase --rebase-merges: avoid "empty merges"
 - sequencer: handle post-rewrite for merge commands
 - sequencer: make refs generated by the `label` command worktree-local
 - rebase --rebase-merges: add test for --keep-empty
 - rebase: introduce the --rebase-merges option
 - rebase-helper --make-script: introduce a flag to rebase merges
 - sequencer: fast-forward `merge` commands, if possible
 - sequencer: introduce the `merge` command
 - git-rebase--interactive: clarify arguments
 - sequencer: offer helpful advice when a command was rescheduled
 - sequencer: refactor how original todo list lines are accessed
 - sequencer: make rearrange_squash() a bit more obvious
 - sequencer: avoid using errno clobbered by rollback_lock_file()

 "git rebase" learned "--rebase-merges" to transplant the whole
 topology of commit graph elsewhere.

 Was on hold.  What's the donness of this thing?
 cf. [ref]

There was enough in limbo that it required a v9, and in hindsight that was
a good thing, too, as I prefered to resolve the merge conflicts with
Phillip's patch series myself rather than have you do it.

But I hope v9 is good enough for `master`, even if I agree that it would
be safer to go through `next`.

This patch series, along with the upcoming `sequencer-and-root-commits`
one, is a crucial building block for the two GSoC projects to convert
rebase and rebase -i into builtins.

Ciao,
Dscho