Re: ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14))

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Dec 15, 2022, 12:55 UTC
Message-ID: <c9c2c979-82b3-8be1-1edb-343661cf4b32@dunelm.org.uk>
In-Reply-To: <221215.865yed3tzv.gmgdl@evledraar.gmail.com>

On 15/12/2022 09:14, Ævar Arnfjörð Bjarmason wrote:

Show 32 quoted lines

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