On Tue, Nov 3, 2020 at 6:50 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 11/2/2020 3:43 PM, Elijah Newren wrote: > > This series depends on a merge of en/strmap (after updating to v3) and > > en/merge-ort-api-null-impl. > > > > As promised, here's the update of the series due to the strmap > > updates...and two other tiny updates. > > Hi Elijah, > > I'm sorry that I've been unavailable to read and review your series > on this topic. I'm very excited about the opportunities here, and I > wanted to take your topic and merge it with our microsoft/git fork > so I could test the performance in a Scalar-enabled monorepo. My > branch is available in my fork [1] > > [1] https://github.com/derrickstolee/git/tree/merge-ort-vfs > > However, I'm unable to discover how to trigger your ort strategy, > even for a simple rebase. Perhaps you could supply a recommended > command for testing? > > Thanks, > -Stolee If you want to test performance, you shouldn't test this particular submission, you should test the end result which exists as the 'ort' branch of my repo. It actually passes all the tests rather than just trivial cherry-picks and rebases, and has lots (and lots) of performance work that hasn't even begun at the point of the 'ort-basics' branch. (However, it also contains some unrelated memory cleanup in revision.c, chdir-notify.c, and a number of other places because I was annoyed that a rebase wouldn't run valgrind-free and made it harder to spot my memory leaks. And the day I went hunting those memory "leaks", I went and grabbed some unrelated memory leaks too. If it causes you merge conflicts, let me know and I'll try to create a branch for you that hash the minimal changes outside of merge-ort*.[ch] and diffcore*.[ch]) All that said, for testing either branch you just need to first set pull.twohead=ort in your git config (see https://lore.kernel.org/git/61217a83bd7ff0ce9016eb4df9ded4fdf29a506c.1604360734.git.gitgitgadget@xxxxxxxxx/), or, if running regression tests, set GIT_TEST_MERGE_ALGORITHM=ort.
