발단

hmux를 OSS로 공개하면서, AI Slop으로 마구 만들었던 테스트 케이스들은 따로 공개하지 않고 private으로 관리할 마음을 먹었다. 따라서 hmux(OSS)와 hmux-tester(Private)가 분리되었는데, 처음엔 submodule로 관리해 봤었다.

대충 GPT가 생성한 diagram

• Outer repository: hmux-tester
  │
  ├── tests and harness
  ├── Cargo.toml
  │     └── hmux = { path = "hmux" }
  │
  └── hmux/ : Git submodule

뭔가 고쳐야 할 사항이 생겼을 때 자연스럽게 tester에서 blackbox로 테스트하는 부분과 내부에서 구현하는 것이 따로 적용되니 좋았는데…

전개

뭔가 작업할 일이 생겨서 평소대로 worktree를 만들어보니, 아뿔싸 submodule은 worktree 생성할때 포함되지 않는 것이다. git submodule update --init을 실행하더라도, worktree에서의 작업물을 main으로 올리는 데 번거로워진다 - worktree 안의 submodule은 사실 원본 repo를 새로 clone한 녀석이기 때문에 거기서 바로 repo에 올려야 한다 - worktree만의 장점이라고 할 수 있는 branch 관리가 번거로워진다.

고민

뭔가 변경사항이 있다고 해서 여러 모듈에 걸친 변경사항을 만드는 게 맞는 것일까요? regression이 생겼으면 먼저 tester 패키지에 해당 regression을 표현할 수 있는 테스트를 만들고, 프로젝트 결과물이 해당 테스트를 통과하지 못함을 보인 다음에 작업을 해서 해당 테스트를 통과하도록 만들면 되는 것이 아닌가? 뭔가 변경사항 하나를 atomic하게 관리하는 git commit의 컨셉이랑 submodule이랑은 안맞는 게 아닌가?

submodule이 마음처럼 스무스하게 통합되지 않으니 여러모로 기존 관념이랑 안맞는 부분까지 불거져서, 아무래도 submodule을 쓰기로 했던 초기 결정을 뒤집어야 하나 고민해보게 되었다.

Decoupling test harness with project

이미 테스터 프로젝트는 대부분의 테스트 케이스들이 tmux 프로토콜만을 이용해서 통신하고 있었으니 큰 의존성은 없다고 할 수 있다. 물론 알게모르게 이런저런 유틸리티 클래스들을 가져다 쓰고 있던게 있지만…

대충 GPT가 생성한 diagram

• hmux repository                 hmux-conformance repository
  │                               │
  ├── production executable ◄─────┤ HMUX_BIN runtime testing
  ├── implementation library      ├── black-box tests
  ├── internal tests              ├── minimal wire client
  └── Ghostty-specific tests      ├── tmux oracle manager
                                  └── independent screen decoder

다만 뭔가 use case가 생겼을 때 두 개의 repository에 각각 작업을 해야 하게 됐다는 점은 불만이다. 이전에는 하나의 프롬프트로 할 수 있었던 일을 이제는 각 repo에 맞게 나눠줘야 한다.

• 야, 이 use case에 해당하는 test case를 만들어줘
• 야, test case를 통과하지 못하고 있거든? 왜 그런지 분석해서 고쳐봐

결론

git submodule은 아무래도 추천할 만한 셋업은 아닌 것 같다.