본문 바로가기
비전공자 IT 이야기/TIL (Today I Learn)

git merge strategy

by firewood tokyo 2022. 5. 28.

어제 다른 동료의 작업기록을 확인하던 중 평소와 다른점이 눈에 띄어서 좀 찾아봤다.

 

기본 머지방법이 바뀌었다고 함.

대충 찾아보니 2.32.x 언저리에서 바꾼듯하다.

-- https://github.com/git/git/blob/master/Documentation/RelNotes/2.32.0.txt
* The test framework has been taught to optionally turn the default
   merge strategy to "ort" throughout the system where we use
   three-way merges internally, like cherry-pick, rebase etc.,
   primarily to enhance its test coverage (the strategy has been
   available as an explicit "-s ort" choice).

도큐멘트는 2.33.1 에서 업데이트 되긴 했는데, ort가 추가된 것 뿐이고 아직 기본정책으로는 설정되지 않았던 것 같다.

-- https://git-scm.com/docs/merge-strategies/2.33.1


commit 67feccd3ba4566392774b8ed9492d7169031d4bb
Author: Elijah Newren <newren@gmail.com>
Date:   Wed Aug 4 23:50:53 2021 +0000

    merge-strategies.txt: add coverage of the `ort` merge strategy

    Acked-by: Derrick Stolee <dstolee@microsoft.com>
    Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Elijah Newren <newren@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index b54bcf68f2..210f0f850b 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -95,6 +95,20 @@ subtree[=<path>];;
        is prefixed (or stripped from the beginning) to make the shape of
        two trees to match.

+ort::
+       This is meant as a drop-in replacement for the `recursive`
+       algorithm (as reflected in its acronym -- "Ostensibly
+       Recursive's Twin"), and will likely replace it in the future.
+       It fixes corner cases that the `recursive` strategy handles
+       suboptimally, and is significantly faster in large
+       repositories -- especially when many renames are involved.
++
+The `ort` strategy takes all the same options as `recursive`.
+However, it ignores three of those options: `no-renames`,
+`patience` and `diff-algorithm`.  It always runs with rename
+detection (it handles it much faster than `recursive` does), and
+it specifically uses `diff-algorithm=histogram`.
+
 resolve::
        This can only resolve two heads (i.e. the current branch
        and another branch you pulled from) using a 3-way merge

 

해서.. 한번 확인해볼까 하고 생각했는데...

$ git --version
git version 2.20.1

$ sudo apt install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
git is already the newest version (1:2.20.1-2+deb10u3).
Calculating upgrade... Done

으윽.. 데비안은 못쓴다 ㅋㅋ

 

windows용 git bash 가 5/10에 릴리스 되어있는 걸 보니 아마 동료분은 이걸로 업데이트를 했나 보다.

https://github.com/git-for-windows/git/releases/tag/v2.36.1.windows.1

 

 

 

※ 밑에 기록한 링크는 찾아봤다는 기록으로, 이해를 했다는 것은 아님을 밝혀둡니다.

https://git-scm.com/docs/merge-strategies#:~:text=ort,a%203%2Dway%20merge%20algorithm.

 

Git - merge-strategies Documentation

The merge mechanism (git merge and git pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X arguments to git merge and/or git pull. ort This is the

git-scm.com

https://github.com/git/git/commits/v2.36.1

 

GitHub - git/git: Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the

Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documen...

github.com

https://github.com/git/git/blob/master/merge-ort.c

 

GitHub - git/git: Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the

Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documen...

github.com

 

 

 

- firewood

댓글