On Tue, Jan 5, 2021 at 6:23 AM Derrick Stolee <stolee@xxxxxxxxx> 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...
