Git 3.0은 SHA-256 기본 전환 예고, 2.56은 git history drop 추가

git add --resolved는 진짜 좋은 아이디어임. 나도 바로 쓸 듯.

sha1에서 sha256으로 바꾸면 force push로 이력 전체를 다시 써야 하는 거 아님? 그럼 취약점 원천이 엄청 늘어나는 거 아닌가.

그게 어떻게 취약점이 되는 건지 잘 모르겠는데.

일단 새 저장소 기본값만 바뀌는 걸로 알고, sha1 지원은 안 없어져서 기존 저장소는 당분간 안 바뀜. 굳이 바꾸려면 새 저장소로 이력을 import하고 다들 다시 clone하게 만드는 방식일 수도 있고.

커밋 내용이랑 메시지가 옛 트리와 바이트 단위로 같은지 검사하는 도구를 만들면 되는데, 그런 게 git에 내장됐으면 좋겠음.

왜 그냥 sha1이랑 sha256을 둘 다 계산해서 당분간 병행하지? 아니면 sha1 객체를 감싸서 건드리지 말라고 표시하는 객체 타입을 만들든가.

Rust를 유행이라 강요하는 건 좀 아쉬움.

그냥 하는 게 아니라 Rust 코드가 더 안전하다고 보는 거임.

C로 바이너리 파일 파서를 짜면 CVE가 쏟아지고 Rust에는 그게 없다는 증거가 이미 충분함. '똑똑한 프로그래머는 C로 버그 안 짠다'는 변명은 이제 안 통함. 발표 링크도 있더라.

내가 아는 Rust 도입 코드베이스는 다 메인테이너가 원해서 했는데, git은 강요인가? 강요당한 메인테이너 사례를 아는 사람 있나.

솔직히 C가 훨씬 더 강요됨. /usr/include를 C가 차지하고 nsswitch 같은 것도 동적 C 라이브러리 필요함. Rust는 프로그램이 선택하는 것뿐임.

reftable 말고, 느린 파일 대신 제대로 된 데이터베이스 쓸 계획은 없나?

'제대로'가 관계형이라는 뜻인가, ACID라는 뜻인가, 기존 DB 소프트웨어를 쓰라는 뜻인가?

파일시스템도 제대로 된 DB임. Linus가 성능 때문에 파일시스템을 썼고, 당시엔 저장소 하나에 ref가 수백 개일 거라 예상했음. 쓰임새가 바뀐 거지.

GitHub가 sha256에 발목 잡힌 게 놀랍지도 않음. IPv6도 안 하는 회사임. 시스템 근본을 못 바꾸니까 주변만 만지작거리는 거지.

Git 3.0에서 나쁜 기본값들은 다 고치나?

그 나쁜 기본값이 뭔지 궁금함. 설정을 바꿔야 하나 고민 중임.