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

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

Elijah Newren <newren@gmail.com> writes:

> 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)

OK.

>   * 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?)

It is always preferrable to fast-track a smaller and less noisy
change that is focused on fixing a bug.

>   * 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.)

Yup, I do not think I mind tentatively dropping the piecemeal
"improvements" bits if it makes it easier to solidify the foundation
to build on.  You guys decide.

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

Just getting overlooked and nobody bothered to ping the topic ;-)

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

These record the committer dates, which is much closer to the date
the version of the patches were exposed to public testing for the
first time, and probably is more appropriate than the author date to
use to judge how long each topic has been "cooked".

> 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?

Again, just getting overlooked and nobody bothered to ping the
topic; also I haven't had chance to give these patches serious
enough reading they deserve yet.