Hi Jake, On Mon, Nov 2, 2020 at 10:52 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Mon, Nov 2, 2020 at 1:28 AM Jacob Keller <jacob.keller@xxxxxxxxx> wrote: > > > > On Thu, Oct 29, 2020 at 1:34 PM Elijah Newren via GitGitGadget > > <gitgitgadget@xxxxxxxxx> wrote: > > > > > > In this series, I show the new merge API I have developed in merge-ort, and > > > show how it differs from that provided by merge-recursive. I do this in four > > > steps, each corresponding to a patch. > > > > > > > I'm definitely excited by this project. I'm curious if you have any > > further implementation as a WIP that could be played with to see the > > end result of the new merging? > > > > I definitely like this approach where you work in smaller increments > > to make the implementation easier to review! > > I usually keep the 'ort' branch of https://github.com/newren/git > functional (no promises, though). It has lots of ifdefs, super ugly > commits, todos & fixmes, and random additional (non-code) files where > I was tracking various things I was working on, so the code and the > tree may not be super readable, but it should be usable (and passes > all the tests) -- just set pull.twohead=ort in your git config, or set > the environment variable GIT_TEST_MERGE_ALGORITHM=ort. > > One warning: git cherry-pick --continue fails with "Cannot specify > both --continue and --strategy"; my handling to set a --strategy > option when pull.twohead was set apparently needs some tweaks. If you > spot any bugs or other issues, let me know. In addition to fixing this "cherry-pick --continue" bug last Monday, I discovered a bug yesterday while re-merging all the merge commits in the linux kernel causing it to fail an assertion. I'm surprised I hadn't hit that sooner, but if you're testing it out you may want to update your copy to the latest version of the 'ort' branch (make sure it has commit 067e5c1a38, "merge-ort: fix bug with cached_target_names not being initialized in redos", 2020-11-06).
