Hi Junio (& Matheus), On Thu, Jan 7, 2021 at 5:41 AM Junio C Hamano <gitster@xxxxxxxxx> 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. <CABPp-BGMX3wb7LiS1HkJpGveoW3J1oR0vVHbKTF5+qYLRF+59g@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/ > * 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@xxxxxxxxxxxxxxxxxxxxxx/; 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@xxxxxxxxx/ > * 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@xxxxxxxxxxxxxxxxxxxxxx/ 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.
