From: Phillip Wood Date: Thu, 15 Dec 2022 12:55:34 GMT Subject: Re: ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Message-ID: In-Reply-To: <221215.865yed3tzv.gmgdl@evledraar.gmail.com> On 15/12/2022 09:14, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Dec 14 2022, Junio C Hamano wrote: > >> * ag/merge-strategies-in-c (2022-08-10) 14 commits >> . sequencer: use the "octopus" 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-one-file: rewrite in C >> . update-index: move add_cacheinfo() to read-cache.c >> . merge-index: add a new way to invoke `git-merge-one-file' >> . merge-index: drop the index >> . merge-index: libify merge_one_path() and merge_all() >> . t6060: add tests for removed files >> . t6060: modify multiple files to expose a possible issue with merge-index >> >> An attempt to rewrite remaining merge strategies from shell to C. >> >> Tired of waiting for too long. >> source: <20220809185429.20098-1-alban.gruin@gmail.com> > > I submitted a v9 of this during Taylor's maintainership, but it fell > between the cracks. I've submitted a rebased-on-master v10 now (there > were some conflicts): > https://lore.kernel.org/git/cover-v10-00.12-00000000000-20221215T084803Z-avarab@gmail.com/ > > It's just the "prep" patches, the real meaty part is converting the > merge drivers, which will come after. Some of the performance numbers > for those are really impressive... I think splitting this in two is a good idea as there were only a couple of outstanding issues with the first half of Alban's V8. When you posted V9 I looked at the range-diff hoping to see a couple of localized changes addressing those issues. Instead it looks like you've rewritten most of the patches that people have already spent a considerable time reviewing. I don't think it is a good use of reviewers' time to essentially start reviewing again from scratch. Best Wishes Phillip