Hacker News 의견

• "vim을 누가 작성했는가" 분석과 관련하여, 워크플로우에 따라 내부 기여자가 더 많이 기여한 것으로 보일 수 있음

  • 패치나 풀 리퀘스트가 내부 기여자에 의해 병합 전에 재포맷되면, 동일한 작업이 두 번 계산되거나 재포맷한 사람에게만 기여가 귀속될 수 있음
  • 결과가 틀린 것은 아니지만, 기여 과정에 대한 검토 없이 결과에서 의미를 도출할 때는 주의가 필요함

• 이 도구는 정말 멋짐. 하루를 마무리하기 전에 잠시 사용해봤음

  • 개인적인 위시리스트는 다음과 같음
    • 블레임 기반 통계. Bob과 Alice의 기여를 보는 것도 좋지만, 모듈/파일의 실질적인 소유자를 보여주는 것이 더 유용할 것임
    • 패턴 기반 포함/제외 지원. 예를 들어, 테스트에 사용되는 json 파일이나 자동 생성된 파일의 통계는 보고 싶지 않음
    • 설정 파일 지원. git 저장소에 선호 설정을 저장할 수 있는 TOML 기반의 파일이 있으면 좋겠음
    • 더 나은 패키징. 예를 들어, v0.6의 리눅스 tarball에는 애플 관련 "쓰레기"가 포함되어 있고, gnu tar가 아카이브 형식 불일치를 경고함

• git 블레임은 많은 사람들이 오해하고 있음. 누가 했는지가 아니라, 어떤 커밋이 원인인지에 대한 것임

• git-who를 git who로 호출할 수 있음. 글로벌 Git 설정에서 별칭을 설정하면 됨

  • 별칭 없이도 작동함. 기본적으로 git whatever는 경로에서 git-whatever를 찾아 실행함

• 저사양 버전으로 "nerdwars"라는 별칭을 사용하여 "git shortlog -ns --no-merges"를 실행함. 이는 프로젝트의 주요 기여자를 파악하는 좋은 방법임

• Gitlab/Github는 제출된 병합 요청이 수정된 코드 라인의 마지막 작성자에게 자동으로 이메일을 보내는 기능을 추가해야 함

• 이 도구는 훌륭함. 앱의 각 릴리스에서 AI와 인간이 작성한 코드 양을 추적하기 위해 git-blame 회계를 사용함

  • "블레임 스크립트"가 저장소 크기가 커지면서 느려지고 있음. 캐싱을 추가하려고 했음
  • 파일 패턴에 기반하여 통계를 제한하는 기능을 추가할 생각이 있는지 궁금함

• tig는 멋진 TUI git 프론트엔드이며, 아름다운 tig blame 서브 커맨드를 가지고 있음

• git에서 놓치고 있는 것은 개발자가 작성한 라인 수나 커밋 수가 아님. 오히려 다음과 같은 것임

  • 누가 이 라인을 삭제했는가
  • 누가 이 메서드의 소유자인가

• 어떤 사람들은 두 개의 다른 이메일을 사용하여 커밋함. 예를 들어, 집 컴퓨터와 회사 컴퓨터에서 각각 다른 이메일을 사용함. 이를 동일한 것으로 정의할 수 있으면 좋겠음