Re: What's cooking in git.git (Jan 2021, #01; Wed, 6)

Hi Junio (& Matheus),

On Thu, Jan 7, 2021 at 5:41 AM Junio C Hamano [off-list ref] wrote:

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

Larger picture provided last week[1].  I would now say that:
  * mt/rm-sparse-checkout needs some small changes (Matheus: I'm happy
to tweak the patch and add a Helped-by: Elijah to it if you want me to
push those changes)
  * the bug fix part of mt/grep-sparse-checkout could possibly be
broken out and merged now (Matheus: similar question here...do you
want help with this?)
  * the other parts of mt/grep-sparse-checkout should probably wait
off based on Stollee's sparse-index work mentioned later in that
thread (Matheus: I'm so sorry we've delayed your series for so long.
I feel bad.  But Stollee is proposing some rather big changes that
could significantly affect this and several other things.)

[1] https://lore.kernel.org/git/CABPp-BGJ_Nvi5TmgriD9Bh6eNXE2EDq2f8e8QKXAeYG3BxZafA@mail.gmail.com/ (local)

* en/merge-ort-recursive (2020-12-16) 4 commits
  (merged to 'next' on 2020-12-22 at 0dbf60011f)
 + merge-ort: implement merge_incore_recursive()
 + merge-ort: make clear_internal_opts() aware of partial clearing
 + merge-ort: copy a few small helper functions from merge-recursive.c
 + commit: move reverse_commit_list() from merge-recursive
 (this branch uses en/merge-ort-2 and en/merge-ort-impl; is tangled with en/merge-ort-3 and en/ort-conflict-handling.)

 The ORT merge strategy learned to synthesize virtual ancestor tree
 by recursively merging multiple merge bases together, just like the
 recursive backend has done for years.

 Will merge to 'master'.

Thanks.

* en/merge-ort-3 (2020-12-15) 11 commits
 - merge-ort: add implementation of type-changed rename handling
 - merge-ort: add implementation of normal rename handling
 - merge-ort: add implementation of rename collisions
 - merge-ort: add implementation of rename/delete conflicts
 - merge-ort: add implementation of both sides renaming differently
 - merge-ort: add implementation of both sides renaming identically
 - merge-ort: add basic outline for process_renames()
 - merge-ort: implement compare_pairs() and collect_renames()
 - merge-ort: implement detect_regular_renames()
 - merge-ort: add initial outline for basic rename detection
 - merge-ort: add basic data structures for handling renames
 (this branch uses en/merge-ort-2 and en/merge-ort-impl; is tangled with en/merge-ort-recursive and en/ort-conflict-handling.)

 Rename detection is added to the "ORT" merge strategy.

Is there a reason this is being held back in seen?  It was submitted
and reviewed[2] before en/merge-ort-recursive which you've marked for
merging to master.  I'm not aware of any outstanding review issues,
and think it's ready to merge down.

[2] https://lore.kernel.org/git/xmqqh7om7mdc.fsf@gitster.c.googlers.com/ (local);
and note that the one (embarrassing) issue highlighted in that revew
was addressed at
https://lore.kernel.org/git/pull.812.v3.git.1608056886.gitgitgadget@gmail.com/ (local)

* en/diffcore-rename (2021-01-04) 9 commits
 - diffcore-rename: remove unnecessary duplicate entry checks
 - diffcore-rename: accelerate rename_dst setup
 - diffcore-rename: simplify and accelerate register_rename_src()
 - t4058: explore duplicate tree entry handling in a bit more detail
 - t4058: add more tests and documentation for duplicate tree entry handling
 - diffcore-rename: reduce jumpiness in progress counters
 - diffcore-rename: simplify limit check
 - diffcore-rename: avoid usage of global in too_many_rename_candidates()
 - diffcore-rename: rename num_create to num_destinations

 File-level rename detection updates.

I'm curious again about your workflow and the meanings of your
messages.  Here, I'm surprised by the change in date; in [2] you
listed it as 2020-12-14.  Do you update the dates when you pull in new
versions of the patch series?  (In particular, I submitted one just
before the new year that did nothing more than correct the
'unneccessary' typo in a commit message.)  Again, not a big deal, I'm
just trying to understand.

[2] https://lore.kernel.org/git/xmqq3608duhp.fsf@gitster.c.googlers.com/ (local)

Anyway, I'm not aware of any outstanding requests for this series; I
think it's ready to start merging down.  Are there issues you are
aware of that you want to see fixed?

* en/stash-apply-sparse-checkout (2020-12-01) 3 commits
 - stash: fix stash application in sparse-checkouts
 - stash: remove unnecessary process forking
 - t7012: add a testcase demonstrating stash apply bugs in sparse checkouts

 "git stash" did not work well in a sparsely checked out working
 tree.

 Will merge to 'next'.

Thanks.