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