Programing

git으로 이름이 바뀐 파일의 로그를 실제로 표시하는 방법은 무엇입니까?

crosscheck 2020. 7. 16. 08:14
반응형

git으로 이름이 바뀐 파일의 로그를 실제로 표시하는 방법은 무엇입니까?


나는 git을 처음 접했고 이전에는 Subversion을 사용했습니다.

파일 이름이 바뀌면 대부분의 그래픽 git 프론트 엔드 및 IDE 플러그인이 파일 기록을 표시 할 수없는 것으로 나타났습니다. 내가 사용할 때

git log --follow

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

Linus Torvalds에 따르면 --follow 스위치는 "SVN noob"입니다. 심각한 git 사용자는 사용하지 않습니다.

--follow는 어쨌든 부모 또는 훌륭한 개정 그래프와 같은 것에 대해 전혀 알지 못하는 전 SVN 사용자를 만족시키기위한 총 핵입니다.

완전히 기본적이지는 않지만 현재 "--follow"구현은 실제로 필수적인 것이 아니라 개정 워킹 논리에 기반한 빠른 전처리 작업입니다.

문자 그대로는 "실제 git 기능"이 아닌 "SVN noob"지원자로 설계되었습니다. 아이디어는 당신이 큰 그림에서 물질의 이름을 바꾸는 (깨진) 사고의 사고 방식에서 벗어날 것이라는 것이 었습니다.

내 질문 : 하드 코어 git 사용자는 파일 이름을 바꿀 때 어떻게 파일의 기록을 얻습니까? 이것을하는 '실제'방법은 무엇입니까?


나는 Linus가 주장하는 일반적인 드라이브는 소금 한 덩어리로 이것을 받아 들인다는 것입니다. 하드 코어 git 사용자들은 "파일"의 역사에 대해 신경 쓰지 않습니다. 내용 전체가 의미있는 기록을 가지고 있기 때문에 내용을 git 저장소에 넣습니다.

파일 이름 바꾸기는 경로 사이를 이동하는 작은 "콘텐츠"의 특별한 경우입니다. git 사용자가 기능적으로 "pickaxe"로 추적 할 수있는 파일 사이를 이동하는 기능이있을 수 있습니다 (예 :) log -S.

다른 "경로"변경에는 파일 결합 및 분할이 포함됩니다. git은 실제로 이름을 바꾼 파일과 복사 (또는 이름을 바꾸고 삭제 한 것으로 간주)하는 파일을 신경 쓰지 않고 트리의 전체 내용을 추적합니다.

git은 많은 버전 제어 시스템이 매우 파일 중심적인 곳에서 "전체 트리"사고를 권장합니다. 이것이 바로 git이 "filenames"보다 "paths"를 더 자주 참조하는 이유입니다.


당신이 직면 한 것과 정확히 같은 문제가 있습니다. 답을 드릴 수는 없지만 Linus가 2005 년에 작성한 이 이메일을 읽을 수 있다고 생각합니다 . 이는 매우 적절하며 문제를 처리하는 방법에 대한 힌트를 줄 수 있습니다.

… 이름 변경이 중요하지 않기 때문에 내부 이유로 인해 (즉 효율적인 델타를 허용하기 위해) 이름 변경을 추적하지 않는 SCM은 근본적으로 손상되었다고 주장합니다. 그들은 당신을 돕지 않으며, 당신이 어쨌든 관심이없는 것이 아닙니다 .

중요한 것은 "이것이 어디에서 왔는가"를 찾는 것이며, git 아키텍처는 실제로 다른 어떤 것보다 훨씬 잘합니다.

이 블로그 게시물에서 참조한 것으로 실용적인 솔루션을 찾는 데 유용 할 수 있습니다.

이 메시지에서 Linus는 이상적인 콘텐츠 추적 시스템을 통해 어떻게 코드 블록이 현재 형태로 만들어 졌는지 알 수있었습니다. 파일의 현재 코드 블록에서 시작하여 기록으로 돌아가 파일을 변경 한 커밋을 찾습니다. 그런 다음 커밋의 변경 사항을 검사하여 파일을 변경하는 커밋이 관심있는 코드 블록에 닿지 않을 수 있으므로 커밋 된 코드 블록이 수정되었는지 확인하십시오. 파일.

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

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

git에서는 Linus의 궁극적 인 콘텐츠 추적 도구가 아직 완전히 자동화 된 방식으로 존재하지 않습니다. 그러나 중요한 성분의 대부분은 이미 사용 가능합니다.

이에 대한 진행 상황을 계속 알려주십시오.


파일 이름이 바뀌면 대부분의 그래픽 git 프론트 엔드 및 IDE 플러그인이 파일 기록을 표시 할 수없는 것으로 나타났습니다.

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

  • SourceTree는 파일 로그를 볼 때 왼쪽 하단에 "이름이 바뀐 파일 따르기"체크 상자가 있습니다
  • TortoiseGit의 왼쪽 하단에있는 로그 창에 "이름 바꾸기"확인란이 있습니다.

Git UI 도구에 대한 추가 정보 :


참고 : git 2.9 (2016 년 6 월)는 다음과 같은 "버기"특성을 상당히 향상시킵니다 git log --follow.

SZEDER Gábor ( )의 commit ca4e3ca (2016 년 3 월 30 일)를 참조하십시오 . ( Junio ​​C Hamano의해 합병 -- 커밋 26effb8 , 2016 년 4 월 13 일)szeder
gitster

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/fileA/file -> B/file)

기술적으로 잘못되지는 않았지만 사용자뿐만 아니라 이름 변경 정보를 기반으로 결정을 내리는 git 명령 (예 : 이름 변경 후 ' git log --follow other-dir/A/file'follow ' dir/B/file') 도 혼동됩니다 .

This behavior is a side effect of commit v2.0.0-rc4~8^2~14 (diffcore-rename.c: simplify finding exact renames, 2013-11-14): the hashmap storing sources returns entries from the same bucket, i.e. sources matching the current destination, in LIFO order.
Thus the iteration first examines 'other-dir/A/file' and 'dir/B/file' and, upon finding identical content and basename, reports an exact rename.


On Linux, I have verified that SmartGit and GitEye is able to follow renames when following the history of a particular file. However, unlike gitk and GitEye, SmartGit shows a separate file view and repository view (which contains the directory structure but not the list of files contained within)

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

반응형