Hi Junio,

On Tue, 27 Oct 2020, Junio C Hamano wrote:

> * ag/merge-strategies-in-c (2020-10-06) 11 commits
>  - sequencer: use the "octopus" merge strategy without forking
>  - sequencer: use the "resolve" strategy without forking
>  - merge: use the "octopus" strategy without forking
>  - merge: use the "resolve" strategy without forking
>  - merge-octopus: rewrite in C
>  - merge-recursive: move better_branch_name() to merge.c
>  - merge-resolve: rewrite in C
>  - merge-index: don't fork if the requested program is `git-merge-one-file'
>  - merge-index: libify merge_one_path() and merge_all()
>  - merge-one-file: rewrite in C
>  - t6027: modernise tests
>
>  The resolve and octopus merge strategy backends have been rewritten
>  in C.

From where I sit, this is ready for `next`.

Ciao,
Dscho

P.S.: I recently mused about the `pu -> seen` rename, and how the rest of
the integration branches' names could be renamed, too. It did strike me as
somewhat unfortunate that `master` is not called `next`, because it
essentially hosts the changes lined up for the next version. And what is
currently `next` could become `cooking` instead. Or `kitchen`. Or
`cauldron`. And in my musing's universe, there would not be any `maint`
branch, only `maint-<version>` branches à la `maint-2.29`...