sweet-search 2.10.5, Git worktree별 색인으로 변경분만 갱신

본문

AI 코딩 에이전트용 로컬 코드 검색 도구 sweet-search가 v2.10.5에서 연결된 Git worktree마다 별도 색인을 준비합니다. worktree는 한 저장소의 여러 브랜치를 서로 다른 작업 디렉터리에서 동시에 다루는 방식입니다. 기존에는 검색 색인이 main checkout을 기준으로 움직여 worktree에서만 새로 만든 코드가 결과에서 빠질 수 있었습니다.

sweet-search는 저장소를 한 번 색인한 뒤 여러 검색 도구를 에이전트에 연결합니다. 자연어 질문에는 키워드 검색과 코드 임베딩 결과를 결합하고 다시 순위를 매겨 관련 코드 블록을 찾습니다. 정확한 문자열을 찾는 grep, 파일 안에서 의미에 맞는 부분을 고르는 검색, 심볼의 호출 관계를 보는 도구도 같은 색인을 사용합니다. 설정 명령이 에이전트 환경을 연결하고, 첫 색인 뒤에는 백그라운드 프로세스가 작업 트리의 편집 내용을 반영합니다.

여러 worktree를 쓰면 검색과 파일 읽기가 서로 다른 상태를 가리킬 수 있습니다. 이전 방식은 검색할 때 main checkout의 색인을 읽으면서 파일 내용은 현재 worktree에서 가져왔습니다. 그래서 worktree에서만 추가한 문자열이나 함수는 검색 결과에 나타나지 않을 수 있었습니다. 각 worktree를 별도로 전체 색인하면 이 문제를 피할 수 있지만 저장소 전체를 다시 처리해야 했습니다.

v2.10.5는 첫 ss-* 호출을 계기로 worktree 전용 색인을 백그라운드에서 만듭니다. main checkout의 색인을 복제한 뒤 내용 해시가 같은 파일은 새 worktree의 파일 상태에 연결하고, 해시가 다른 파일은 다시 색인하도록 대기열에 넣습니다. macOS APFS와 Linux에서는 copy-on-write 복제를 사용하고, 일반 복사는 디스크 공간이 충분할 때만 진행합니다. 전용 색인은 main 색인 아래 worktree별 경로에 두며 해당 작업 디렉터리의 .sweet-search가 그 색인을 가리킵니다.

색인 준비가 끝나면 worktree 전용 유지 관리 프로세스가 변경된 파일을 추적합니다. 검색 계층과 네이티브 grep도 새 색인을 사용하므로 worktree에서 고친 코드가 이후 검색에 들어옵니다. worktree를 삭제할 때는 관련 프로세스를 멈추고 고아 색인을 정리합니다. 이전 색인에 남은 파일 상태를 그대로 섞지 않도록 복제와 상태 전환도 순서에 맞춰 처리합니다.

별도 색인은 첫 ss-* 호출 뒤 백그라운드에서 준비됩니다. 색인이 준비되는 동안에는 검색이 main checkout의 색인을 참조할 수 있으며 worktree에만 있는 텍스트는 그 기간 결과에서 빠질 수 있다고 프로젝트가 안내합니다. 구현 커밋은 자체 테스트에서 색인 전환에 약 1분이 걸릴 수 있다고 설명합니다. 같은 커밋에 적힌 66개 파일 저장소 테스트에서는 전체 색인에 2분 44초가 걸렸고 worktree 색인은 0.2초 만에 준비됐으며, 변경된 파일 2개는 3.4초에 색인됐습니다. 이 수치는 해당 테스트 저장소에서 나온 결과입니다. 기존 공유 색인 방식은 SWEET_SEARCH_WORKTREE_INDEX=0으로 선택할 수 있습니다.

자료: GitHub / 정리·해설: Trawling