From: Elijah Newren Date: Wed, 06 Jan 2021 19:20:37 GMT Subject: Re: [PATCH v2 00/10] merge-ort: add more handling of basic conflict types Message-ID: In-Reply-To: <5f6d5428-36ce-3e91-4916-8968ac1b8686@gmail.com> On Tue, Jan 5, 2021 at 6:23 AM Derrick Stolee wrote: > > On 12/31/2020 9:34 PM, Elijah Newren via GitGitGadget wrote: > > This series depends on en/merge-ort-2 (it does not depend on en/merge-ort-3 > > or en/merge-ort-recursive). > > > > This series adds handling of additional basic conflict types (directory/file > > conflicts, three-way content merging, very basic submodule divergence > > reconciliation, and different filetypes). This series drops the number of > > test failures under GIT_TEST_MERGE_ALGORITHM=ort by 211 (from 1448 to 1237). > > > > Further, if en/merge-tests, en/merge-ort-3, en/merge-ort-recursive, and this > > series are all merged down (in any order), then collectively they drop the > > number of test failure under GIT_TEST_MERGE_ALGORITHM=ort from 1448 down to > > 60. > > I finished reading the rest of the patches. They are well-organized to > present the merging logic in small chunks. > > While this is a very dense series, the proof is in the test cases. I > look forward to testing the ort algorithm in CI builds and start enabling > it in my repositories. > > Your patch organization will help if there are bugs that we won't catch > until we can enable this merge algorithm more widely, as we can blame to > these well-crafted patches to assist with debugging. Thanks for taking a look, as always. Your comments reminded me that I intended to dig into your code coverage reports and try to figure out if there are parts of merge-ort.[ch] (and diffcore-rename.c) that are uncovered by any testcases. I bet there are some. There were certainly many in merge-recursive, and while I've extended the testsuite coverage over the years, I never did it with the aid of a code coverage tool...