Hi Junio, On Mon, 2 Nov 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > 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`. > > I just went back to the thread. > > https://lore.kernel.org/git/20201005122646.27994-1-alban.gruin@xxxxxxxxx/ > > It seems that the topic saw quite a few comments and help by Phillip > Wood in its earliest iteration, but I didn't see any review from > those other than myself on the last iteration v3, and the review > comments on the iteration haven't been acted upon yet. > > That was why I threw the topic in "needs review" bucket. The later > half of the series got no comments (I lost steam after reviewing the > earlier half) and I suspect they would have be adjusted for fixes > and improvements done to polish the earlier parts, so I am not sure > where your "ready for 'next'" comes from. Sorry, I had missed your latest suggestion had not been addressed yet. Maybe I am a bit over-eager to get rid of those scripts... Ciao, Dscho
