Re: What's cooking in git.git (Jul 2021, #04; Mon, 19)

[Derrick Stolee <stolee@gmail.com>]

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@gmail.com/.

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