Re: What's cooking in git.git (Mar 2021, #05; Wed, 17)

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> Will do; I'll also point out a few topics that have been reviewed but
> haven't been picked up yet.
>
>> * en/ort-perf-batch-9 (2021-03-10) 8 commits
>>  - diffcore-rename: avoid doing basename comparisons for irrelevant sources
>>  - merge-ort: skip rename detection entirely if possible
>>  - merge-ort: use relevant_sources to filter possible rename sources
>>  - merge-ort: precompute whether directory rename detection is needed
>>  - merge-ort: introduce wrappers for alternate tree traversal
>>  - merge-ort: add data structures for an alternate tree traversal
>>  - merge-ort: precompute subset of sources for which we need rename detection
>>  - diffcore-rename: enable filtering possible rename sources
>>  (this branch uses en/ort-perf-batch-8.)
>>
>>  More ort.
>
> Can I suggest an alternate title?  "merge-ort optimization of skipping
> irrelevant renames" or anything that gets the idea of "skipping
> irrelevant renames" in there.

Thanks.

>> * en/ort-perf-batch-8 (2021-02-26) 10 commits
>>   (merged to 'next' on 2021-03-07 at f03b2c1acd)
>>  + diffcore-rename: compute dir_rename_guess from dir_rename_counts
>>  + diffcore-rename: limit dir_rename_counts computation to relevant dirs
>>  + diffcore-rename: compute dir_rename_counts in stages
>>  + diffcore-rename: extend cleanup_dir_rename_info()
>>  + diffcore-rename: move dir_rename_counts into dir_rename_info struct
>>  + diffcore-rename: add function for clearing dir_rename_count
>>  + Move computation of dir_rename_count from merge-ort to diffcore-rename
>>  + diffcore-rename: add a mapping of destination names to their indices
>>  + diffcore-rename: provide basic implementation of idx_possible_rename()
>>  + diffcore-rename: use directory rename guided basename comparisons
>>  (this branch is used by en/ort-perf-batch-9.)
>>
>>  Rename detection rework continues.
>>
>>  Will cook in 'next'.
>
> I think it's ready to merge to master.

When a "will merge to 'next'" topic is merged to 'next', its label
is mechanically rewritten to "will merge to 'master'" outside the
pre-release freeze, and to "will cook in 'next'" while pre-release
freeze.  So for the topics labelled with "Will cook in 'next'", by
default they should turn into "Will merge to 'master'".

That was why I was specifically asking for topics to be KICKED OUT
of 'next', to give them a fresh start without having to do "oops,
this was a mistake, let's patch it up".

> Here are some reviewed topics that haven't been cooking yet, that I
> personally think are worth picking up (at least for seen and probably
> for next rather soonish):

Thanks for a useful list of topics.  At this point, topics that are
not picked up are not because they are not ready/worth, but because
there are too many of them sent during the pre-release freeze.

> * My ort-perf-batch-10 ("skip even more irrelevant renames") series:
> https://lore.kernel.org/git/8422759a-a4a3-4dc6-4ae7-4a61896b9946@gmail.com/;
> (the review comment there is addressed by the next patch series in
> this list)

There are 8, 9 and now this 10 in flight, which is two topics too
many to have in flight at the same time X-<.  Luckily -8 seems to be
good for 'master', so there is no risk of having to rewind it
anymore, which makes the burden of having to carry multiple dependent
topics at the same time.