js/rebase-recreate-merge, was Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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. <nycvar.QRO.7.76.6.1804210017020.4241@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>

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