Git worktrees isolerer ikke kodeagenten din, og klonen koster det samme

«En worktree var aldri en grense.» Setningen kommer fra utvikleren bak Fletch, en macOS-app som kjører kodeagenter, i en gjennomgang av hva en linked worktree faktisk deler med repoet den henger på. Poenget er ikke en feil i Git, men en misforståelse av hva verktøyet lover.

I en linked worktree er .git en fil, ikke en katalog. Git deler tilstanden i to bunker. Per worktree ligger HEAD, indeksen, ORIG_HEAD og noen bisect- og rebase-filer. Alt annet peker tilbake til opphavsrepoet: objektlageret, refs og brancher, .git/config, stashen og .git/hooks.

Den siste er den farlige. En hook installert fra innsiden av en worktree blir installert for foreldrerepoet, og kjører som deg, i ditt repo, neste gang du selv committer. Config-en er delt på samme måte, så en agent som kjører et helt vanlig git config i sin egen worktree skriver til hovedrepoets .git/config og kan bytte ut e-postadressen dine egne commits attribueres til. Og siden det finnes én refs/stash per repo, kan én agent poppe stashen til en annen.

«Det er ikke agentens commit. Det er din, i ditt eget repo, med en forfatterlinje noe annet valgte» — utvikleren bak Fletch

De to vanlige motforslagene holder ikke. Innstillingen extensions.worktreeConfig er av som standard, og hjelper bare hvis den som skriver aktivt velger git config --worktree. Å flytte hookene ut med core.hooksPath er sirkulært: core.hooksPath er selv config, og config er delt, så worktreen kan peke den dit den vil. Flagget --separate-git-dir feiler likedan, siden hver worktree fortsatt deler det .git ble flyttet til.

Det samme rammer containere, og der blir konsekvensen større. Å gi en container en linked worktree betyr å montere foreldrerepoets ekte .git, fordi det er der worktreens egen tilstand ligger. En skrivbar .git/hooks på vertssiden av den monteringen kjører på verten, og containeren slutter å bety noe.

Argumentet for å bruke worktrees har vært at en klone per agent koster for mye. Målt mot en full klone av git/git, 81 772 commits og et arbeidstre på 58 MB, stemmer det ikke. Forfatteren skriver selv at han hadde kostnadsdelen feil i en tidligere versjon av innlegget, og målte den på nytt på git 2.50.1.

Forskjellen mellom de raske variantene er støy. En git clone --shared bruker 870 ms og de samme 58,9 MB, men isolerer refs, config, stash og hooks der worktreen deler alt sammen. Den låner objekter gjennom alternates, så kilderepoet må ligge i fred: sletter du det eller kjører aggressiv git gc på det mens klonene lever, kan du prune objekter en klone fortsatt peker på. En vanlig hardlenket klone er mer robust, fordi hardlenken holder inoden i live av seg selv.

Konklusjonen er enkel nok til å handle på: worktree når et menneske sitter ved tastaturet, klone når noe annet gjør det.

Hva bør du gjøre?

1. Kjør git config --get user.email i hovedrepoet ditt hvis du har hatt agenter i worktrees, og bekreft at adressen fortsatt er din.
2. Se over .git/hooks og verdien av core.hooksPath etter oppføringer du ikke la inn selv.
3. Bytt til git clone --shared eller en vanlig lokal klone per agent. Målingene viser at det koster de samme sekundene og de samme megabytene.