git로 이름이 바뀐 파일의 로그를 실제로 표시하는 방법

git로 이름이 바뀐 파일의 로그를 실제로 표시하는 방법

나는 Git에 비교적 처음입니다.전에 서브버전(SVN)을 사용한 적이 있습니다.

대부분의 그래픽 Git 프런트엔드 및 IDE 플러그인은 파일 이름이 변경된 경우 파일의 기록을 표시할 수 없습니다.사용할 때

git log --follow

명령줄에서 이름을 바꿀 수 있는 전체 로그를 볼 수 있습니다.

Linus Torvalds(대체 링크)에 따르면,--follow스위치는 "SVN noob"입니다. 심각한 Git 사용자는 스위치를 사용하지 않습니다.

--follow는 완전한 해킹으로, 어쨌든 부모 역할이나 멋진 수정판 그래프와 같은 것들에 대해 전혀 알지 못하는 전 SVN 사용자들을 만족시키기 위한 것입니다.

완전히 근본적인 것은 아니지만, "--follow"의 현재 구현은 정말로 필수적인 것이 아니라 수정된 보행 논리에 적용된 빠른 전처리입니다.

말 그대로 "현실적인 기능"이 아닌 "SVN noob" 즐거움을 위해 설계되었습니다.이 아이디어는 큰 그림에서 이름을 바꾸는 것이 중요하다고 생각하는 (깨진) 사고방식에서 벗어날 수 있다는 것이었습니다.

하드코어 Git 사용자는 파일 이름이 변경되었을 때 파일의 기록을 어떻게 얻습니까?이것을 하는 '진짜' 방법은 무엇입니까?

제 생각에 리누스의 요점 뒤에 있는 일반적인 추진력은 하드코어 Git 사용자들이 "파일"의 기록에 대해 전혀 신경 쓰지 않는다는 것입니다.콘텐츠 전체가 의미 있는 이력을 가지고 있기 때문에 콘텐츠를 Git 저장소에 저장합니다.

파일 이름 변경은 경로 간에 이동하는 "내용"의 작은 특수한 경우입니다.가 " "Pickaxe")으로할 수 수 .으로 추적할 수 있는 파일 간을 이동하는 기능이 있을 수 있습니다.log -S).

다른 "경로" 변경에는 파일 결합 및 분할이 포함됩니다. Git는 어떤 파일이 이름이 바뀌었다고 생각하는지, 어떤 파일이 복사되었다고 생각하는지(또는 이름이 바뀌거나 삭제되었다고 생각하는지)는 중요하지 않습니다.트리의 전체 내용을 추적할 뿐입니다.

많은 버전 제어 시스템이 파일 중심적인 반면 Git는 "전체 트리" 사고를 장려합니다.이것이 Git가 "파일 이름"보다 "경로"를 더 자주 언급하는 이유입니다.

저는 당신이 직면하고 있는 것과 똑같은 문제를 가지고 있습니다.제가 답변을 드릴 수는 없지만, 리누스가 2005년에 작성한 이 이메일을 읽을 수 있다고 믿습니다. 이 이메일은 매우 적절하며 문제를 처리하는 방법에 대한 힌트를 줄 수 있습니다.

…이름 변경을 추적하려는 SCM은 내부적인 이유로(즉, 효율적인 델타를 허용하기 위해) 그렇지 않은 한 근본적으로 손상된다고 주장합니다. 정확히 이름 변경이 중요하지 않기 때문입니다.그들은 당신을 돕지도 않고, 어쨌든 당신이 관심을 가졌던 것도 아닙니다.

중요한 것은 "이것이 어디서 온 것인가"를 찾는 것입니다. Git 아키텍처는 실제로 그것을 매우 잘 수행합니다. 다른 어떤 것보다 훨씬 낫습니다.…

저는 이 블로그 게시물에서 이를 참조했으며, 실행 가능한 솔루션을 찾는 데도 유용할 수 있습니다.

메시지에서 라이너스는 이상적인 콘텐츠 추적 시스템이 어떻게 코드 블록이 현재 모양으로 왔는지를 찾을 수 있는지에 대해 설명했습니다.파일의 현재 코드 블록에서 시작하여 기록으로 돌아가서 파일을 변경한 커밋을 찾습니다.그런 다음 커밋의 변경 내용을 검사하여 관심 코드 블록이 해당 블록에 의해 수정되었는지 확인합니다. 파일을 변경하는 커밋은 관심 코드 블록을 건드리지 않고 파일의 다른 일부에만 적용될 수 있습니다.

커밋하기 전에 파일에 코드 블록이 존재하지 않았음을 발견하면 커밋을 더 자세히 검사합니다.다음과 같은 여러 가지 가능한 상황 중 하나임을 알 수 있습니다.

1. 위원회는 코드 블록을 도입했습니다.커밋의 저자는 당신이 그것의 기원을 사냥하고 있던 그 멋진 특징의 발명가였습니다(또는 버그를 도입한 유죄 당사자); 또는
2. 파일에 코드 블록이 존재하지 않았지만 서로 다른 파일에 동일한 복사본 5개가 존재했으며, 이 모든 것이 커밋 후에 사라졌습니다.위원회의 작성자는 단일 도우미 기능을 도입하여 중복된 코드를 리팩터링했습니다.
3. (특별한 경우로) 커밋하기 전에 현재 관심 있는 코드의 블록 자체를 포함하는 파일은 존재하지 않았지만 거의 동일한 내용을 포함하는 다른 파일이 존재했으며, 관심 있는 코드의 블록은 그 당시 파일의 다른 모든 콘텐츠와 함께 해당 다른 파일에 존재했습니다.그것은 커밋 후에 사라졌습니다.커밋 작성자가 파일 이름을 변경하면서 파일 이름을 약간 수정했습니다.

실제로 라이너스의 궁극적인 콘텐츠 추적 도구는 아직 완전히 자동화된 방식으로 존재하지 않습니다.하지만 대부분의 중요한 재료들은 이미 구할 수 있습니다.

이에 대한 진행 상황을 계속 알려주시기 바랍니다.

파일 이름이 변경된 경우 대부분의 그래픽 깃 프론트엔드 및 IDE 플러그인이 파일의 기록을 표시할 수 없는 것 같습니다.

이제 인기 있는 Git UI 도구가 이 기능을 지원한다는 것을 알게 되어 기쁩니다.수십 개의 Git UI 도구를 사용할 수 있으므로 모두 나열하지는 않겠지만, 예를 들어 다음과 같습니다.

• 파일 로그를 볼 때 소스 트리의 왼쪽 아래에 "이름 변경된 파일 따라하기" 확인란이 있습니다.
• TorothyGit에는 왼쪽 하단의 로그 창에 "이름 변경" 확인란이 있습니다.

Git UI 도구에 대한 자세한 정보:

• http://git-scm.com/downloads/guis
• https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools

참고: git 2.9 (2016년 6월)는 의 "버기" 특성을 상당히 개선할 것입니다.git log --follow:

SZEDER Garbor szeder()의 commit ca4e3ca (2016년 3월 30일)를 참조하십시오.
^{(주니오 C 하마노에 의해 합병 -- -- 2016년 4월 13일 커밋 26effb8에서)}

diffcore: 이름 바꾸기 탐지 중 동일한 파일의 반복 순서 수정

두 경로가 'dir/A/file및 'dir/B/file콘텐츠가 동일하고 상위 디렉토리의 이름이 변경됩니다(예: ').git mv dir other-dir그 때에diffcore에는 다음과 같은 정확한 이름이 보고됩니다.

renamed:    dir/B/file -> other-dir/A/file
renamed:    dir/A/file -> other-dir/B/file

(반전은 여기에 기록합니다.B/file -> A/file,그리고.A/file -> B/file)

기술적으로 틀린 것은 아니지만, 이것은 사용자뿐만 아니라 이름 변경 정보를 기반으로 결정을 내리는 forgit 명령도 혼란스럽게 만듭니다. 예를 예로 들 수 있습니다.git log --follow other-dir/A/file뒤에 'dir/B/file이름을 변경했습니다.

이 동작은 커밋 v2.0.0-rc4~8^2~14의 부작용입니다(diffcore-rename.c정확한 이름 찾기 단순화, 2013-11-14): 소스를 저장하는 해시 맵은 동일한 버킷의 항목, 즉 현재 대상과 일치하는 소스를 LIFO 순서로 반환합니다.
따라서 반복은 먼저 '를 조사합니다.other-dir/A/file및 'dir/B/file그리고 동일한 내용과 기본 이름을 찾으면 정확한 이름 변경을 보고합니다.

---

Git 2.31(2021년 1분기)을 통해 파일 레벨 이름 변경 감지 기능이 향상되었습니다.diffcore.

커밋 350410f(2020년 12월 29일), 커밋 9db2ac5, 커밋 b970b4e, 커밋 ac14de1, 커밋 5c72261, 커밋 81c4bf0, 커밋 ad8a1be, 커밋 00b8cc, 커밋 26a66a6(2020년 12월 11일)을 참조하십시오.newren
^{(주니오 C 하마노에 의해 합병 -- -- 2021년 1월 25일 a5ac31b 커밋)}

diffcore-rename가속시키다rename_dst

^{사인 오프 바이: 엘리야 뉴렌}

register_rename_src() 단히내 부전쌍참다니을 안에서 합니다.rename_src.

그반서해에,서,add_rename_dst()완전히 다른 일을 했습니다.rename_dst.
쌍을 두 쌍을 했습니다.diff_filespec▁the다설▁from를 설정합니다.diff_rename_dst를 .로 이동합니다필드를 로 이동NULL.
되면, 나에짝발견면되가짓기,record_rename_pair() 할당했습니다.diff_filepair경유로diff_queue()그리고 그것을 가리켰습니다.src그리고.dst 당한에에 diff_filespecs.

은 사의이대조의 입니다.register_rename_src()를해위를 .rename_src 및 데이터 구조add_rename_dst()를해위를 .rename_dst데이터 구조는 이상하게 일관성이 없으며 필요 이상으로 많은 메모리와 작업이 필요합니다.
[...] 이 패치는 설정 시간을 약 65% 단축하고 출력 대기열에 최종 쓰기 시간을 약 50% 단축하여 수십 개 패치의 기본 재배치 실행 시간을 3.5% 단축했습니다.

방법은 다음과 같습니다.

git log -M --summary | grep rename | grep BASENAME

그냥 거기에 기본 이름을 넣으면 됩니다.

결과가 너무 많으면 연속적으로 실행할 수도 있습니다.grep각 중간 디렉토리 이름.

Linux에서 SmartGit 및 GitEye가 특정 파일의 기록을 추적할 때 이름을 바꿀 수 있음을 확인했습니다.그러나 Gitk 및 GitEye와 달리 SmartGit은 별도의 파일 보기 및 리포지토리 보기(디렉토리 구조는 포함하지만 포함된 파일 목록은 포함하지 않음)를 표시합니다.

언급URL : https://stackoverflow.com/questions/5743739/how-to-really-show-logs-of-renamed-files-with-git