My Commit Hook Has Ten Documented Fixes. Its Own Guard Clause May Have Kept It From Running on a Single One of My Real Commits.

개요

prepare-commit-msg 훅의 가드 클로즈(guard clause)가 실제 커밋에 적용되지 않는 문제를 발견했으며, 이는 자동화된 커밋 생성 방식이 훅의 예상과 달랐기 때문입니다.

주요 내용

* 다수의 훅 수정에도 불구하고 실제 적용되지 않음: prepare-commit-msg 훅은 타임아웃, argv-too-long, UTF-8 디코딩 오류, --safe-mode 관련 버그, 리포지토리 루트 해석 버그, 속성 제거 정규식 수정 등 10개 이상의 버그가 수정되고 문서화되었으나, 실제 본인이 만드는 커밋에 훅이 실행되는지는 확인하지 않았습니다.
* 가드 클로즈의 숨겨진 조건: 훅의 가드 클로즈 라인 # [ "$2" = "" ] || exit 0은 COMMIT_SOURCE가 비어있지 않으면 훅 실행을 중단합니다. 주석에는 병합 커밋(merge), 스쿼시(squash), 수정(amend) 커밋을 건너뛴다고 명시되어 있으나, -m 옵션을 사용한 커밋(COMMIT_SOURCE가 "message") 또한 간과되었으며, 이는 자동화된 커밋 파이프라인에서 주로 사용되는 방식입니다.
* 자동화된 커밋의 실행 방식: 해당 리포지토리의 대부분 커밋은 자동화된 게시 루틴에 의해 -m 옵션을 사용하여 생성되며, 이는 가드 클로즈에 의해 훅 실행을 막습니다. 따라서 훅의 수정 사항이 실제 자동 커밋에는 적용되지 않았을 가능성이 높습니다.
* 제안된 훅의 동작 방식: 훅의 시스템 프롬프트는 Conventional Commits 형식을 따르는 짧은 커밋 메시지 생성을 지시하지만, 실제 커밋 로그에는 72자 이상인 메시지가 다수 포함되어 있으며, 이는 git diff만으로는 알 수 없는 여러 정보를 포함하는 인간이 작성한 것으로 보입니다.
* 확인 절차의 한계: 훅의 "실시간 검증"은 종종 빈 메시지로 git commit을 실행하여 훅이 메시지를 미리 채우는지만 확인했으며, 이는 가드 클로즈가 적용되지 않는 유일한 커밋 스타일입니다.
* 향후 설계 고려 사항: 가드 클로즈를 완화하여 -m 옵션을 지원하거나, 자동화된 파이프라인이 -m 옵션 대신 훅을 통해 편집기 버퍼를 채우도록 하거나, 훅이 대화형 인간 커밋만을 대상으로 설계되었음을 받아들이는 등의 설계 결정을 내려야 합니다.
* 권고 사항: 에이전트 파이프라인에 pre-commit 또는 prepare-commit-msg 훅을 연결한 경우, 훅이 단순히 작동하는지 확인하는 것을 넘어 자동화가 실제로 사용하는 호출 방식에 대해 훅이 실행되는지 검증해야 합니다.