quoted

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