Wikipedia는 자동 이름 변경 감지에 대해 설명합니다.
간단히 말해, 개정판 N의 파일이 주어지면 개정판 N-1에서 같은 이름의 파일이 기본 조상입니다. 그러나 개정판 N-1에 같은 이름의 파일이없는 경우 Git은 개정판 N-1에만 존재 하고 새 파일 과 매우 유사한 파일을 검색합니다.
이름 바꾸기 탐지는 유사한 파일 탐지로 귀결됩니다. 그 알고리즘이 어디에나 문서화되어 있습니까? 어떤 종류의 변환이 자동으로 감지되는지 아는 것이 좋습니다.
답변:
Git은 파일 이름이 아닌 파일 내용을 추적합니다. 따라서 내용을 변경하지 않고 파일의 이름을 바꾸는 것은 git이 감지하기 쉽습니다. (힘내 추적하지 않고, 수행은 검출 , 사용 git mv또는 git rm과 git add. 효과적으로 동일)
파일이 저장소에 추가되면 파일 이름은 트리 개체에 있습니다. 실제 파일 콘텐츠는 저장소에 이진 대형 개체 ( blob ) 로 추가됩니다 . Git은 동일한 콘텐츠를 포함하는 추가 파일에 대해 다른 Blob을 추가하지 않습니다. 실제로 Git은 콘텐츠가 파일 시스템에 저장되기 때문에 해시의 처음 두 문자는 디렉토리 이름이고 나머지는 그 안에있는 파일 이름입니다. 따라서 이름 바꾸기를 감지하는 것은 해시를 비교하는 문제입니다.
이름이 변경된 파일의 작은 변경 사항을 감지하기 위해 Git은 특정 알고리즘과 임계 값 제한을 사용하여 이름이 변경되었는지 확인합니다. 예를 들어에 대한 -M플래그를 살펴보십시오 git diff. merge.renameLimit(병합 중에 이름 바꾸기 감지를 수행 할 때 고려할 파일 수) 와 같은 구성 값도 있습니다 .
git이 유사한 파일을 처리하는 방법 (즉, 이름 변경으로 간주되는 파일 변환) 을 이해하려면 위에서 언급 한대로 사용 가능한 구성 옵션과 플래그를 탐색하십시오. 방법을 고려할 필요는 없습니다. git이 실제로 이러한 작업을 수행하는 방법을 이해하려면 텍스트의 차이점을 찾는 알고리즘을 살펴보고 git 소스 코드를 읽어보십시오.
알고리즘은 diff, merge 및 log 목적으로 만 적용되며 git이 저장하는 방법에는 영향을주지 않습니다. 파일 내용이 조금만 변경되면 새 개체가 추가됩니다. 해당 수준에서 발생하는 델타 또는 차이가 없습니다. 물론 나중에 델타가 팩 파일에 저장되는 위치에 객체가 압축 될 수 있지만 이는 이름 변경 감지와 관련이 없습니다.
텍스트 간의 유사성을 감지하는 많은 알고리즘이 있으며 버전 제어 시스템은 종종 두 버전 간의 차이 만 저장하기 위해 이미이를 사용합니다. WinMerge와 같은 도구는 줄 내에서도 차이를 감지 할 수있을만큼 똑똑하므로 이러한 알고리즘이이 이름 변경 감지에 사용되지 않는 이유를 알 수 없습니다.
다음은 유사한 텍스트를 감지하는 알고리즘에 대한 설명 입니다. 이러한 알고리즘 중 일부는 자연어에 최적화 될 수 있고 다른 알고리즘은 소스 코드에 대해 더 잘 작동 할 수 있지만 본질적으로 매우 유사합니다.