git commit Filename too long, 윈도우에서 메시지 파일 경로가 길면 생기는 일
블로그 작업을 커밋하려는데 git 이 한 줄 뱉고 멈췄다. Filename too long. 커밋 메시지를 파일로 써 두고 git commit -F 로 넘긴 건데, 그 파일이 AI 도구가 쓰는 임시 폴더 깊숙한 데 있었다. 저장소 파일 이름은 하나도 안 길었는데 왜?
내가 시험한 윈도우 11, git 2.56.0.windows.2(MinGit) 환경에선 메시지 파일의 전체 경로가 141자일 때는 됐고, 282자일 때는 Filename too long 으로 실패했다. 같은 282자 경로도 git -c core.longpaths=true commit -F 로 하면 됐고, 메시지 파일을 짧은 경로로 옮겨도 됐다. 윈도우 레지스트리에서 긴 경로를 켜 둔 PC 였는데도 그랬다.
처음엔 어디가 긴 건지 몰랐다
Filename too long 하면 보통 저장소 안 파일 이름이 길어서 체크아웃이 안 되는 얘기가 먼저 나온다. 근데 내 저장소엔 긴 파일이 없었다. 그날은 급해서 메시지 파일을 $env:TEMP 바로 아래로 옮기고 넘어갔다. 그때 원래 경로가 몇 자였는지는 안 남겨 뒀다.
그래서 오늘 시험용 저장소를 하나 만들어서 다시 해 봤다. 메시지 파일 경로 길이만 바꿔 가면서.
git commit -F 경로 길이로 다시 재현
파일명까지 합친 전체 경로가 141자일 땐 그냥 됐다. 폴더를 두 겹 더 넣어서 전체 282자로 만들었더니 났다. 아래 경로는 가린 거고, 실제로는 파일명까지 포함해 282자였다.
PS> git commit -q -F "<파일명까지 전체 282자인 메시지 파일 경로>"
fatal: could not read log file 'C:/Users/.../commit_message_file_for_long_path_test.txt': Filename too long종료 코드는 128. 오류 문구에 나온 log file 은 -F 로 넘긴 메시지 파일을 가리킨다. 오류에 찍힌 경로도 그 파일이고, 길이만 바꿔서 됐다 안 됐다 하니까 저장소 쪽이 아니라 메시지 파일 경로 문제라고 봤다.
이상한 건 이 PC 레지스트리에 LongPathsEnabled 가 이미 1 로 켜져 있었다는 거다. Microsoft 문서를 보니 레지스트리만 켠다고 모든 프로그램이 긴 경로를 읽는 건 아니었다. 경로 한도 MAX_PATH 는 끝의 널 문자까지 쳐서 260자고, 윈도우 10 1607 부터 여러 Win32 함수에서 이걸 풀 수 있는데 LongPathsEnabled=1 이랑 프로그램 쪽 longPathAware 선언이 둘 다 필요하다고 한다. 다만 이번에 git 이 정확히 어디서 막혔는지 내부까지 확인한 건 아니다.
core.longpaths 랑 짧은 경로, 둘 다 됐다
git 쪽 설정 core.longpaths 를 켜고 같은 282자 경로로 다시 해 봤다. 이번엔 이 명령에만 적용되는 -c 로.
git -c core.longpaths=true commit -q -F "<파일명까지 전체 282자인 메시지 파일 경로>"바로 됐다. Git for Windows 안내에도 긴 경로 지원은 기본으로 꺼져 있고 core.longpaths 로 켤 수 있다고 나와 있다. 단 C 로 된 git 명령에만 해당하고, 스크립트로 된 명령은 켜도 실패할 수 있다고 적혀 있다. commit 은 이번에 된 거고.
메시지 파일을 짧은 데로 옮겨도 됐다.
git commit -q -F "$env:TEMP\gt_msg.txt"나는 그날 이후로 짧은 경로 쪽을 쓰고 있다. 설정을 안 건드려도 되니까 마음이 편해서. git config --global core.longpaths true 로 아예 켜 두는 방법도 있는데 이건 안 해 봤다. 내가 시험한 건 -c 로 한 번 켜는 것까지다.
이번엔 AI 도구가 쓰는 임시 폴더 안에 메시지 파일을 두다가 걸렸다. 커밋을 맡길 때 메시지 파일은 짧은 경로에 두라고 미리 일러두면 편하겠다. 다음엔 PowerShell 로 파일을 쓸 때 명령마다 인코딩이랑 줄바꿈이 어떻게 달라지는지 재 본 얘기를 하려고 한다.