From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Mar 2021, #08; Tue, 30)
Date: Tue, 30 Mar 2021 18:23:09 -0700 [thread overview]
Message-ID: <CABPp-BEmZ-UGNeWs+XS4o0VWZ8=nqrCwJsSBQFYBBJ8Py2XOZg@mail.gmail.com> (raw)
In-Reply-To: <xmqqv99889hh.fsf@gitster.g>
Hi,
On Tue, Mar 30, 2021 at 5:17 PM Junio C Hamano <gitster@pobox.com> wrote:
> [New Topics]
> ...
> * en/ort-perf-batch-11 (2021-03-25) 7 commits
> - merge-ort, diffcore-rename: employ cached renames when possible
> - merge-ort: add helper functions for using cached renames
> - merge-ort: preserve cached renames for the appropriate side
> - merge-ort: avoid accidental API mis-use
> - merge-ort: add code to check for whether cached renames can be reused
> - merge-ort: populate caches of rename detection results
> - merge-ort: add data structures for in-memory caching of rename detection
> (this branch uses en/ort-perf-batch-10, en/ort-perf-batch-9 and en/ort-readiness.)
I was actually slightly surprised you picked this one up this early
given the other three in-flight. I sent it out for review since folks
had reviewed the previous series and discussion on them had been quiet
for a while.
Please note that there is an issue with this series, as noted at
https://lore.kernel.org/git/CABPp-BGrevGj+xrm9bVcX5bp_WRv9cYP+g0hrAtjZK0u=sTHzQ@mail.gmail.com/,
so even if you merge the other series down, this one needs to be
re-rolled at least once first. (I know you normally wouldn't merge
quickly, I just wanted to avoid an accidental merge to next based on
topic name similarity.)
> [Cooking]
...
> * en/ort-perf-batch-10 (2021-03-18) 8 commits
> - diffcore-rename: determine which relevant_sources are no longer relevant
> - merge-ort: record the reason that we want a rename for a file
> - diffcore-rename: add computation of number of unknown renames
> - diffcore-rename: check if we have enough renames for directories early on
> - diffcore-rename: only compute dir_rename_count for relevant directories
> - merge-ort: record the reason that we want a rename for a directory
> - merge-ort, diffcore-rename: tweak dirs_removed and relevant_source type
> - diffcore-rename: take advantage of "majority rules" to skip more renames
> (this branch is used by en/ort-perf-batch-11 and en/ort-readiness; uses en/ort-perf-batch-9.)
>
> I made a mistake of picking these up before they got sufficient
> exposure to the reviewers and ended up a source of potential mess
> when it turns out that any of the earlier ones need rewriting (I
Um...are you by chance conflating my comments linked above on
ort-perf-batch-11, the very latest series, with this series? I
totally agree that ort-perf-batch-11 is in no state for building upon,
hasn't had sufficient review, and even if someone had reviewed it
quickly there hasn't been enough time to allow other reviewers to
chime in...but I haven't sent any subsequent series based on it.
> probably should stop picking up nested series that exceeds reviewer
> bandwidth), but how ready is this and subsequent topics?
I think ort-perf-batch-9, ort-perf-batch-10, and ort-readiness are all
ready to merge to next. All have been reviewed by Stolee to his
satisfaction. ort-readiness was also reviewed by Ævar (and used by
him in testing one of his series and helped him find a bug).
As noted above, ort-perf-batch-11 is not ready; please do not merge that one.
> * en/ort-readiness (2021-03-20) 13 commits
> - Add testing with merge-ort merge strategy
> - t6423: mark remaining expected failure under merge-ort as such
> - Revert "merge-ort: ignore the directory rename split conflict for now"
> - merge-recursive: add a bunch of FIXME comments documenting known bugs
> - merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a conflict
> - t: mark several submodule merging tests as fixed under merge-ort
> - merge-ort: implement CE_SKIP_WORKTREE handling with conflicted entries
> - t6428: new test for SKIP_WORKTREE handling and conflicts
> - merge-ort: support subtree shifting
> - merge-ort: let renormalization change modify/delete into clean delete
> - merge-ort: have ll_merge() use a special attr_index for renormalization
> - merge-ort: add a special minimal index just for renormalization
> - merge-ort: use STABLE_QSORT instead of QSORT where required
> (this branch is used by en/ort-perf-batch-11; uses en/ort-perf-batch-10 and en/ort-perf-batch-9.)
>
> Plug the ort merge backend throughout the rest of the system, and
> start testing it as a replacement for the recursive backend.
As noted above, this series had two reviewers[1,2].
[1] https://lore.kernel.org/git/87pn09iu3j.fsf@evledraar.gmail.com/
[2] https://lore.kernel.org/git/4da61e15-a490-673a-ef15-800321ac9eea@gmail.com/
I'm not aware of any outstanding issues, the reviewers seemed happy as
of 2-3 weeks ago, and I haven't heard anyone else chime in so I'm
inclined to say this one is ready to merge to next.
> * 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 is used by en/ort-perf-batch-10, en/ort-perf-batch-11 and en/ort-readiness.)
>
> The ort merge backend has been optimized by skipping irrelevant
> renames.
>
> Will merge to 'next'.
Thanks, sounds good.
next prev parent reply other threads:[~2021-03-31 1:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 0:14 What's cooking in git.git (Mar 2021, #08; Tue, 30) Junio C Hamano
2021-03-31 1:23 ` Elijah Newren [this message]
2021-03-31 20:18 ` Junio C Hamano
2021-03-31 10:16 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABPp-BEmZ-UGNeWs+XS4o0VWZ8=nqrCwJsSBQFYBBJ8Py2XOZg@mail.gmail.com' \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).