summaryrefslogtreecommitdiff
path: root/contrib/long-running-filter
diff options
context:
space:
mode:
authorLibravatar Elijah Newren <newren@gmail.com>2020-11-02 23:45:34 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-11-02 16:35:50 -0800
commit14c4586c2dfa94d86d71a60481dd20bc5b56e562 (patch)
tree86ef342952fc4a78c51723dfb96b89fb6cae7443 /contrib/long-running-filter
parentfast-rebase: demonstrate merge-ort's API via new test-tool command (diff)
downloadtgif-14c4586c2dfa94d86d71a60481dd20bc5b56e562.tar.xz
merge,rebase,revert: select ort or recursive by config or environment
Allow the testsuite to run where it treats requests for "recursive" or the default merge algorithm via consulting the environment variable GIT_TEST_MERGE_ALGORITHM which is expected to either be "recursive" (the old traditional algorithm) or "ort" (the new algorithm). Also, allow folks to pick the new algorithm via config setting. It turns out builtin/merge.c already had a way to allow users to specify a different default merge algorithm: pull.twohead. Rather odd configuration name (especially to be in the 'pull' namespace rather than 'merge') but it's there. Add that same configuration to rebase, cherry-pick, and revert. This required updating the various callsites that called merge_trees() or merge_recursive() to conditionally call the new API, so this serves as another demonstration of what the new API looks and feels like. There are almost certainly some callsites that have not yet been modified to work with the new merge algorithm, but this represents the ones that I have been testing with thus far. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/long-running-filter')
0 files changed, 0 insertions, 0 deletions