Hi,

On Tue, Dec 8, 2020 at 5:37 PM Junio C Hamano [off-list ref] wrote:

* en/diffcore-rename (2020-12-07) 5 commits
 - diffcore-rename: simplify and accelerate register_rename_src()
 - diffcore-rename: reduce jumpiness in progress counters
 - diffcore-rename: rename num_create to num_targets
 - diffcore-rename: remove unnecessary if-clause
 - diffcore-rename: avoid usage of global in too_many_rename_candidates()

Curious.  I submitted 7 patches for this series.  While one wasn't all
that important (tweaking wording in comments), the final patch was.
Looking at it again, I notice I somehow messed up the commit summary
(missing the "area:" prefix).  Is that why the final commit was
dropped or does something else need to be fixed up too?  And if I
resubmit, do you want the other patch you dropped left out?

* en/merge-ort-2 (2020-12-08) 7 commits
 - merge-ort: add modify/delete handling and delayed output processing
 - merge-ort: add die-not-implemented stub handle_content_merge() function
 - merge-ort: add function grouping comments
 - merge-ort: add a paths_to_free field to merge_options_internal
 - merge-ort: add a path_conflict field to merge_options_internal
 - merge-ort: add a clear_internal_opts helper
 - merge-ort: add a few includes
 (this branch uses en/merge-ort-impl.)

 More "ORT" merge strategy.

 Needs review.

Reviewed by Stolee:
https://lore.kernel.org/git/2ea0aab8-934f-3eaa-e3d0-9ae35a278748@gmail.com/ (local)

(More review is good, of course, I was just surprised by the label.)

[Stalled]

* mt/grep-sparse-checkout (2020-12-06) 10 commits
 - t7817: do not depend on any specific default branch name
 - config: add setting to ignore sparsity patterns in some cmds
 - grep: honor sparse checkout patterns
 - config: correctly read worktree configs in submodules
 - config: make do_git_config_sequence receive a 'struct repository'
 - t/helper/test-config: unify exit labels
 - t/helper/test-config: diagnose missing arguments
 - t/helper/test-config: be consistent with exit codes
 - t1308-config-set: avoid false positives when using test-config
 - doc: grep: unify info on configuration variables
 (this branch is used by mt/rm-sparse-checkout.)

 "git grep" has been tweaked to be limited to the sparse checkout
 paths.


* mt/rm-sparse-checkout (2020-12-08) 1 commit
 - rm: honor sparse checkout patterns
 (this branch uses mt/grep-sparse-checkout.)

 "git rm" follows suit to "git grep" to ignore paths outside the
 sparsity pattern when the sparse checkout feature is in use.

 Need to wait for how these fit in larger picture.
 cf. [ref]

Sorry for taking a while on these.  :-(  I'll try to get back to it soon...

* so/log-diff-merge (2020-11-09) 27 commits
 - doc/git-show: include --diff-merges description
 - doc/rev-list-options: document --first-parent implies --diff-merges=first-parent
 - doc/diff-generate-patch: mention new --diff-merges option
 - doc/git-log: describe new --diff-merges options
 - t4013: add test for --diff-merges=first-parent
 - diff-merges: implement new values for --diff-merges
 - diff-merges: make -m/-c/--cc explicitly mutually exclusive
 - diff-merges: refactor opt settings into separate functions
 - diff-merges: get rid of now empty diff_merges_init_revs()
 - diff-merges: group diff-merge flags next to each other inside 'rev_info'
 - diff-merges: split 'ignore_merges' field
 - diff-merges: fix -m to properly override -c/--cc
 - t4013: add tests for -m failing to override -c/--cc
 - t4013: support test_expect_failure through ':failure' magic
 - diff-merges: revise revs->diff flag handling
 - diff-merges: introduce revs->first_parent_merges flag
 - diff-merges: new function diff_merges_set_dense_combined_if_unset()
 - diff-merges: new function diff_merges_suppress()
 - diff-merges: re-arrange functions to match the order they are called in
 - diff-merges: rename diff_merges_default_to_enable() to match semantics
 - diff-merges: move checks for first_parent_only out of the module
 - diff-merges: rename all functions to have common prefix
 - revision: move diff merges functions to its own diff-merges.c
 - revision: provide implementation for diff merges tweaks
 - revision: factor out initialization of diff-merge related settings
 - revision: factor out setup of diff-merge related settings
 - revision: factor out parsing of diff-merge related options

 "git log" learned a new "--diff-merges=<how>" option.

 Needs review.

I think you can update this to "Awaiting reroll", as per
https://lore.kernel.org/git/87wnxyfz07.fsf@osv.gnss.ru/ (local) .

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

Round 2 got pretty deep reviews by both Stolee and Jonthan Tan, at
least the first 15 patches (which I think were the most crucial to
review).  Both led to some significant restructures of certain
portions.

Round 3 also got some reviews from Ævar.

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"?