Lanes are never pruned after their PR merges (76 lanes / ~128 GB locally)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- git, github, typescript
- Ambito
- developer-experience, tooling
Direzione di ricerca
Start with apps/host/src/manage.ts and apps/app/src/git.ts, then read packages/channel/src/lanes.ts and the lane CLI guidance in AGENTS.md. Trace how channel removal and PR state are handled, and check how git fetch --prune and lane prune report lanes they retain. Done when merged lanes are pruned by the host and retained lanes have a visible reason.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Lanes are never removed after their PR merges. On one dev machine, ace2 had built up 76 lanes taking about 128 GB, and 59 of them belonged to PRs that had already merged. The lane lifecycle (https://lane.lukeed.com/usage/) expects lane prune to remove landed lanes. In practice, nothing in Ace runs it, and with our merge setup it can't recognise most of our lanes as landed anyway.
What's happening
1. Nothing runs lane prune.
- The only mention is in agent instructions:
AGENTS.md:71andAGENTS.md:109say to runlane prune"once it merges". - The agent's turn ends at
gh pr create. The merge happens later on GitHub, and nobody comes back afterwards. remove()inapps/host/src/manage.ts:278removes only the older worktrees kept in the channel directory, and only when a channel is deleted. Lanes created bylane neware deliberately left "forlane pruneorlane rm". Channels that are archived or simply kept retain all their lanes.
2. lane prune didn't treat our merged lanes as landed.
- Per
AGENTS.md:71, prune removes a lane once its remote branch is gone or localmaincontains its work. - Until today githubnext/ace had
delete_branch_on_merge: false, and AGENTS.md says to merge without--delete-branch, so remote branches stayed after merging. Example:fair-ember/canary-0-0-13(#115, merged Oct 5) was still on origin. - PRs are squash-merged, so
mainnever contains the lane's commits. - Lanes from before Ace adopted the lane CLI (in
~/.local/state/ace*/channels/*/lanes, created before about Oct 13) have no landing record fromlane push, so prune reportslanded outside lane. - As a result,
lane lsshowed 63 lanes aspushedand none aslanded.lane prune --dry-runlisted 6 skipped lanes and said nothing about the other 70, so they were invisible as well as kept.
Breakdown at the time:
| Kind | Count | PR status |
|---|---|---|
| Lanes in the channel directory (pre-lane CLI) | 70 | 57 merged, 2 closed, 11 never had a PR |
lane new lanes, .lane/trees |
6 | 2 closed, 4 never had a PR |
Done so far
- "Automatically delete head branches" is now on for githubnext/ace. Merges from now on should delete the remote branch, so
git fetch --prune && lane pruneought to catch them. This hasn't been verified yet on a lane that merged after the change. - One-off local cleanup: I removed 51 merged lanes from the channel directory with
git worktree remove. Each one was clean, and its HEAD equalled the merged PR'sheadRefOid.
Proposal
- Have the host run
git fetch --prune+lane pruneitself.- On host start, or periodically.
- When it sees a channel's PR become merged.
apps/app/src/git.tsalready tracks PR state. - In
remove()when a channel is deleted, instead of leaving its lanes behind.
- Surface lanes prune refuses. The
landed outside laneandcommits main does not havecases should appear somewhere visible, so they aren't left on disk indefinitely. - Retire the pre-lane-CLI path. After a one-time migration that drops merged lanes from the channel directory, the
lanesloop inremove()and therecorded?.pathfallback inpackages/channel/src/lanes.tscan go. - Possibly upstream in lane: have
lane prune --dry-runlist every lane it keeps and why, not only some of them. A lane that ispushedwith an existing remote branch is currently omitted silently.
- Lingua principale
- TypeScript
- Stelle
- 1
- Fork
- 0
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di githubnext/ace2
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
githubnext/ace2#530 · 1 commento ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
githubnext/ace2#437 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
githubnext/ace2#528 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
githubnext/ace2#511 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
githubnext/ace2#506 ·
Tutte le issue di githubnext/ace2
Issue simili
-
area:editor bug issue-form:bug P0 platform:windows review: low
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
1lck/Lithe-IDEA#1388 ·
I maintainer di solito rispondono entro 1 giorno
-
fix(api): isToolAuditEnabled swallows database read errors on auditToolOperations without loggingApertaarea: backend bug priority: low
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
snapotter-hq/SnapOtter#3238 ·
I maintainer di solito rispondono entro 1 giorno
-
rig up --plan times out after 5 s and reports an UNKNOWN outcome while the daemon completes the planAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
filesystem: search_files does not expand non-wildcard excludePatterns like directory_tree doesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
modelcontextprotocol/servers#5216 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno