삭제 된 줄을 어떻게“비난”합니까?

삭제 된 줄을 어떻게“비난”합니까?

---

git blame수정 및 추가 된 줄에는 훌륭하지만 이전의 특정 커밋에 존재하는 줄이 결국 삭제 된 시점을 어떻게 알 수 있습니까? 나는 생각하고 bisect있지만 더 편리한 것을 기대하고 있었다.

[당신이 묻기 전에 :이 경우에, 나는 단지 git log -p코드 라인을 검색하고 (a) 일부 바보가 방금 이전 커밋에서 생명선을 삭제했으며 (b) 나는 그 바보였습니다]

---

줄의 내용을 알고 있다면 다음과 같은 경우에 이상적인 사용 사례입니다.

git log -S <string> path/to/file

해당 문자열의 인스턴스를 소개하거나 제거하는 커밋을 보여줍니다. -G<regex>정규 표현식과 동일한 기능을 수행하는 것도 있습니다 ! 자세한 내용 man git-log은 -G및 -S옵션 또는 pickaxe (이 기능의 이름)를보고 검색하십시오.

이 -S옵션은 실제로 git-blame설명 페이지 의 맨 페이지 헤더에도 언급되어 git log -S...있습니다.

---

당신이 정말로 원하는 것은

git blame --reverse START..END filename

에서 맨 페이지 :

뒤로가 아니라 앞으로 걸어가십시오. 선이 나타난 개정을 표시하는 대신 선이 존재하는 마지막 개정을 표시합니다. 이것은 비난의 경로가 START에 존재하는 START..END와 같은 범위의 수정이 필요합니다.

을 사용하면 git blame reverse행이 표시된 마지막 커밋을 찾을 수 있습니다. 여전히 커밋을 가져와야합니다.

다음 명령을 사용하여 반전 된 자식 로그를 표시 할 수 있습니다. 표시된 첫 번째 커밋은 해당 줄이 마지막으로 나타나는 시간이며 다음 커밋은 변경되거나 제거 될 때입니다.

git log --reverse --ancestry-path COMMIT^..master

---

Cascabel 답변을 완성하기 위해

git log --full-history -S <string> path/to/file

여기에 언급 된 것과 같은 문제가 있었지만 지점의 병합 커밋이 되돌려지고 다시 병합되어 문제의 줄을 효과적으로 제거했기 때문에 줄이 누락 된 것으로 나타났습니다. --full-history플래그 방지는 이러한 커밋을 건너 뛰는.

---

git blame --reverse 를 사용 하면 줄이 삭제 된 위치에 가까이 갈 수 있습니다 . 그러나 실제로 줄이 삭제 된 개정을 가리 키지 는 않습니다 . 그것은 가리키는 마지막 라인이었다 개정 존재 . 그런 다음 다음 개정판 이 일반 커밋이면 운이 좋으며 삭제 개정판을 얻습니다. OTOH, 다음 개정판이 merge commit 인 경우 상황이 약간 나빠질 수 있습니다. difflame 을 만들기위한 노력의 일환으로 나는이 문제를 해결 했으므로 이미 상자에 파이썬이 설치되어 있고 시도해보고 싶다면 더 이상 기다리지 말고 어떻게 진행되는지 알려주십시오.

https://github.com/eantoranz/difflame

---

병합 커밋에 숨겨진 변경 사항

병합 커밋은 변경 사항을 git-log 출력에서 ​​자동으로 숨 깁니다. 곡괭이와 후진은 모두 변화를 찾지 못했습니다. 그래서 내가 원하는 줄이 추가되고 나중에 제거되었고 그것을 제거 한 병합을 찾고 싶었습니다. 파일 git log -p -- path/file히스토리 만 추가 된 것으로 나타났습니다. 내가 찾은 가장 좋은 방법은 다음과 같습니다.

git log -p -U9999 -- path/file

변경 사항을 검색 한 후 "^ commit"을 역방향으로 검색하십시오. 첫 번째 "^ commit"은 파일의 마지막 행이 커밋 된 것입니다. 두 번째 "^ commit"은 사라진 후입니다. 두 번째 커밋은 제거한 것일 수 있습니다. 은 -U9999파일 모두 최대 9999 선입니다 가정 (파일이 변경 될 때마다 후) 전체 파일 내용을 표시하기위한 것입니다.

무차별 대입을 통해 관련 병합을 찾습니다 (가능한 모든 병합 커밋을 첫 번째 상위와 비교하고 많은 커밋에 대해 실행)

git log --merges --pretty=format:"git diff %h^...%h | grep target_text" HEAD ^$(git merge-base A B) | sh -v 2>&1 | less

(수정 필터를 더 제한하려고 시도했지만 문제가 발생하여 이것을 권장하지 않습니다. 내가 찾고 있던 추가 / 제거 변경 사항은 다른 시간에 병합 된 다른 지점에 있었으며 A ... B는 포함하지 않았습니다. 변경 사항이 실제로 메인 라인에 병합되었습니다.)

이 두 가지 커밋 (그리고 복잡한 git-history가 많이 제거됨) 으로 git tree를 보여 주십시오.

git log --graph --oneline A B ^$(git merge-base A B) (A는 위의 첫 번째 커밋, B는 위의 두 번째 커밋)

A의 역사와 B의 역사를 빼고 A와 B의 역사를 빼십시오.

다른 버전 : (일반 git-history-tree가 아닌 경로를보다 선형으로 표시하는 것으로 보이지만 일반 git-history-tree를 선호합니다) :

git log --graph --oneline A...B

2 점이 아닌 3 점-3 점은 "r1 r2 --not $ (git merge-base --all r1 r2)를 의미합니다. 이것은 r1 (왼쪽) 또는 r2 (오른쪽) 중 하나에서 도달 할 수있는 커밋 세트입니다. )이지만 둘 다가 아닙니다. " -출처 : "man gitrevisions"

참고 URL : https://stackoverflow.com/questions/4404444/how-do-i-git-blame-a-deleted-line