Hi, On Tue, Dec 8, 2020 at 5:37 PM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxx/ (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. <CABPp-BGMX3wb7LiS1HkJpGveoW3J1oR0vVHbKTF5+qYLRF+59g@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx/ . > * 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"?
