.mailmap 테스터

열에 아홉은 네 번째 형식인데 이름이 맞지 않는 경우입니다. Jane Doe <jane@corp.example> jane <ci@build.example>는 작성자 이름이 정확히 jane인 커밋만 잡습니다(대소문자는 무시). 같은 주소라도 release-bot 이름으로 남은 커밋은 그대로인데, 이름 기반 항목이 빗나가면 그 주소의 일반 항목으로 넘어가고 그런 항목이 없을 수 있기 때문입니다. Commit Name 부분을 빼면 그 주소의 모든 커밋에 걸립니다. 다음으로 흔한 원인은 히스토리에 아예 없는 주소(git log --format='%an <%ae>' | sort -u로 확인하고 +tag 형태와 GitHub users.noreply 주소를 살피세요), 그리고 git이 찾는 위치인 작업 트리 최상단에 .mailmap이 없는 경우입니다.

조회 방식과 교체 범위가 다릅니다. 앞의 셋은 커밋 주소만으로 등록됩니다. Proper Name <commit@x>는 이름을 바꾸고, <proper@x> <commit@x>는 주소만 바꾸며 커밋의 이름은 그대로 두고, Proper Name <proper@x> <commit@x>는 둘 다 바꿉니다. 네 번째는 커밋 주소 앞에 이름을 하나 더 두고 그 이름으로도 등록되므로, 양쪽이 모두 맞는 커밋에만 적용됩니다. 한 주소에 두 종류가 함께 있으면 git은 이름 기반 표를 먼저 보고 일반 항목을 대비책으로 씁니다. 파일은 스크립트가 아니라 지도이므로 쓴 순서는 상관없습니다.

되지 않습니다. 조회는 신원마다 한 번만 일어나고 결과를 다시 넣지 않으므로, A에 있던 신원은 B에서 멈춥니다. 같은 파일 안에 B가 다른 항목의 키로 있어도 마찬가지입니다. 파일이 여러 해에 걸쳐 자랄 때 이 문제가 드러납니다. 예전 노트북 주소를 회사 주소로 접어 넣고, 나중에 그 회사 주소를 개인 주소로 접어 넣으면 첫 묶음은 따라오지 않습니다. 해결책은 모든 항목이 최종 신원을 직접 가리키게 하는 것입니다. 이 도구는 정식 주소가 다른 항목의 키이기도 한 경우를 표시합니다.

키의 양쪽 모두 구분하지 않습니다. 주소와 이름 모두 대소문자를 무시하므로 커밋의 <OLD@EXAMPLE.COM>은 <old@example.com>으로 쓴 항목에 걸리고, Old Name으로 등록된 네 번째 형식 항목은 OLD NAME도 잡습니다. 그 밖에는 문자 그대로입니다. 공백 두 칸짜리 Two Spaces는 한 칸짜리 Two Spaces와 다르고, git은 신원 줄에서 이름 앞의 문자를 잘라 내지 않으므로 들여쓴 신원은 그 들여쓰기를 이름의 일부로 안고 다녀 이름 기반 항목에 걸리지 않습니다. 꺾쇠 안도 다듬지 않아 < old@x >는 어떤 커밋에도 없는 공백 섞인 키가 됩니다.

둘 다 일부씩 이깁니다. git은 커밋 주소마다 정식 이름 하나와 정식 주소 하나를 두고, 각 항목은 자신이 가진 필드만 기록합니다. 그래서 Alpha <alpha@x> <dup@x> 다음에 <beta@x> <dup@x>가 오면 결과는 Alpha <beta@x>가 됩니다. 첫 줄의 이름과 둘째 줄의 주소가 합쳐진, 파일 어디에도 없는 신원입니다. 같은 필드를 가진 뒤 항목만 앞을 덮어씁니다. 주소가 중복되면 어떤 줄이 조용히 아무 기여도 하지 않게 되는 이유이고, 이 도구가 이름과 주소의 출처가 다른 행을 표시하는 이유이기도 합니다.

아닙니다. 지금 서 있는 저장소의 작업 트리에서 표시 시점에 읽히며 git log, git shortlog, git blame, git check-mailmap과 --use-mailmap 또는 log.mailmap 설정으로 실행한 명령이 적용합니다. 각 커밋 객체에 기록된 작성자는 그대로이고, 그것이 핵심입니다. 이 방식으로 이름을 고치면 비용이 없고 서명도 깨지지 않지만, 히스토리를 다시 쓰면 그 아래 모든 커밋 아이디가 바뀝니다. 대신 이 파일은 체크아웃된 곳에서만 효과가 있어서, 자체 기여자 목록을 만드는 서비스는 GitHub을 포함해 이 파일을 참조하지 않습니다.