On 7/19/2021 9:52 PM, Elijah Newren wrote: ... >> * en/ort-perf-batch-14 (2021-07-13) 7 commits >> - merge-ort: restart merge with cached renames to reduce process entry cost >> - merge-ort: avoid recursing into directories when we don't need to >> - merge-ort: defer recursing into directories when merge base is matched >> - merge-ort: add a handle_deferred_entries() helper function >> - merge-ort: add data structures for allowable trivial directory resolves >> - merge-ort: add some more explanations in collect_merge_info_callback() >> - merge-ort: resolve paths early when we have sufficient information >> >> Further optimization on "merge -sort" backend. >> >> Reviews? > > Stolee reviewed it; he posted numerous comments and helpful > suggestions throughout the series. I sent in a new series > incorporating all his suggestions, though I'm still waiting to hear > back if that addresses things sufficiently for him. I just looked at v3 and like it. I wanted to look closely at the new struct, but it translates rather well from the previous version so there are no surprises. I mentioned on the v3, but that version LGTM. >> * ds/commit-and-checkout-with-sparse-index (2021-07-14) 5 commits >> - checkout: stop expanding sparse indexes >> - sparse-index: recompute cache-tree >> - commit: integrate with sparse-index >> - p2000: compress repo names >> - p2000: add 'git checkout -' test and decrease depth >> (this branch uses ds/status-with-sparse-index.) >> >> "git checkout" and "git commit" learn to work without unnecessarily >> expanding sparse indexes. >> >> Will merge to 'next'. > > Please wait; he's going to post some fixes. See > https://lore.kernel.org/git/91b81577-3ff8-3845-75d1-c47e8a42406e@xxxxxxxxx/. Yes, please wait. I spent longer than expected working out the details of that patch that we were debating. It turns out to be important, and I have a new organization of patches that demonstrates this more clearly, along with tests demonstrating how directory/file conflicts are currently broken in the non-sparse case. I got distracted thinking about the original design of the df_conflict_entry and wandered through several code moves into ee6566e ([PATCH] Rewrite read-tree, 2005-09-05), which was not particularly illuminating. I'm giving myself the day to see if I can figure this out enough to fix the full-checkout case, but I'm not optimistic. Expect a v2 soon that describes the trade-offs of the current implementation. >> * ds/status-with-sparse-index (2021-07-14) 16 commits >> - t1092: document bad sparse-checkout behavior >> - fsmonitor: integrate with sparse index >> - wt-status: expand added sparse directory entries >> - status: use sparse-index throughout >> - status: skip sparse-checkout percentage with sparse-index >> - diff-lib: handle index diffs with sparse dirs >> - dir.c: accept a directory as part of cone-mode patterns >> - unpack-trees: unpack sparse directory entries >> - unpack-trees: rename unpack_nondirectories() >> - unpack-trees: compare sparse directories correctly >> - unpack-trees: preserve cache_bottom >> - t1092: add tests for status/add and sparse files >> - t1092: expand repository data shape >> - t1092: replace incorrect 'echo' with 'cat' >> - sparse-index: include EXTENDED flag when expanding >> - sparse-index: skip indexes with unmerged entries >> (this branch is used by ds/commit-and-checkout-with-sparse-index.) >> >> "git status" codepath learned to work with sparsely populated index >> without hydrating it fully. >> >> Will merge to 'next'. > > Yep, sounds good; thanks. Thanks! -Stolee