Re: What's cooking in git.git (Dec 2020, #01; Tue, 8)

From: Jonathan Tan <jonathantanmy@google.com>
Date: Dec 10, 2020, 02:57 UTC
Message-ID: <20201210025722.1645961-1-jonathantanmy@google.com>
In-Reply-To: <CABPp-BGcyRURykePOafjcE1z9J8U5awF=PZw1ufx+8Ow+k3j3w@mail.gmail.com>

Show 34 quoted lines

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