> > * en/merge-ort-impl (2020-12-06) 21 commits > > - merge-ort: free data structures in merge_finalize() > > - merge-ort: add implementation of record_conflicted_index_entries() > > - tree: enable cmp_cache_name_compare() to be used elsewhere > > - merge-ort: add implementation of checkout() > > - merge-ort: basic outline for merge_switch_to_result() > > - merge-ort: step 3 of tree writing -- handling subdirectories as we go > > - merge-ort: step 2 of tree writing -- function to create tree object > > - merge-ort: step 1 of tree writing -- record basenames, modes, and oids > > - merge-ort: have process_entries operate in a defined order > > - merge-ort: add a preliminary simple process_entries() implementation > > - merge-ort: avoid recursing into identical trees > > - merge-ort: record stage and auxiliary info for every path > > - merge-ort: compute a few more useful fields for collect_merge_info > > - merge-ort: avoid repeating fill_tree_descriptor() on the same tree > > - merge-ort: implement a very basic collect_merge_info() > > - merge-ort: add an err() function similar to one from merge-recursive > > - merge-ort: use histogram diff > > - merge-ort: port merge_start() from merge-recursive > > - merge-ort: add some high-level algorithm structure > > - merge-ort: setup basic internal data structures > > - Merge branch 'en/strmap' into en/merge-ort-impl > > (this branch is used by en/merge-ort-2.) > > > > Needs review. > > I think I've addressed all the feedback in v4 (which is sadly labelled > as v2 due to switching from send-email to gitgitgadget part way > through the series). If there's more review needed, I'd say getting a > thumbs-up or thumbs-down from Stolee and Jonathan on whether I > addressed their feedback adequately would be great, and having someone > give a look over the 2nd-to-last and 4th-to-last patches would always > be a plus. Was that what you had in mind in marking this as "Needs > review"? Rereading my feedback and the parts of the v4 patch set that correspond to my feedback, my comments (which were more about clarity anyway - I didn't notice any correctness or performance issues) have been addressed adequately. But to be fully sure, I would need to reread the patches to ensure that nothing unexpected was introduced. :-P (If nobody does this, I can do this - hopefully by the end of the week.) I wonder if it would be worth splitting this branch into the first 15 patches (which I reviewed, and which has more of an algorithmic focus) and the last 5 patches (which I didn't review, and which has more of an integration-into-Git focus). That way, the last 5 wouldn't hold up the first 15.
