ag/merge-strategies-in-c, was Re: What's cooking in git.git (Oct 2020, #04; Tue, 27)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 2, 2020, 02:37 UTC
Message-ID: <nycvar.QRO.7.76.6.2011020333440.18437@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqmu079rbv.fsf@gitster.c.googlers.com>

Hi Junio,

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

Show 15 quoted lines

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