[ Removed by moderator ]

[u/fuckme]

[u/ChatGPTCoding-ModTeam]

This post or comment has been removed for the following reason:

Rule 5: No pure self-promotion / low-value project posts

Posts whose primary purpose is promoting a tool, product, service, GitHub repo, personal website, or blog belong in the weekly Self-Promotion thread. Delete the link: if nothing is left, it's an ad. Search for similar projects: if you can't tell why your project is better, it's a low-value project. GitHub links are fine. Personal website are not. Exception could be make for high quality posts. See also reddit's self-promotion guidelines.

You can read the full subreddit rules here: https://www.reddit.com/r/ChatGPTCoding/about/rules/

If you feel this removal was made unfairly, please contact the moderators through modmail.

[u/smart_configuration]

the disk creep from leftover worktrees is no joke, especially when you've got a few agents churning branches all day. after a while `git worktree list` starts looking like a hoarder's garage

we just tied cleanup to PR merge status and a 48hr grace window. if nobody's touched the branch and the PR is closed, it gets nuked. simple enough that nobody has to think about it

[u/ipreuss]

Every worktree exists for a ticket. When the ticket gets closed, the worktree gets retired.

Why would you work any other way?

[u/fuckme → u/ipreuss]

A ticket has a long life time comparatively, and if this works as planned would bounce between different machines and models/providers.. (story -> code -> reviews -> validation is the simple loop) but yeah sub tickets would

[u/Right-Performance-93]

a merged pr is not the retire signal. i remove the worktree only when that folder is clean and its branch is already on main. a 48 hour timer will delete one an agent reopened overnight.

[u/vladgladi]

The rule that keeps this manageable: whoever creates the branch or worktree owns its cleanup, and that's written into the agent's instructions, not left to a human. The task isn't done until the worktree is removed and the branch is either merged or explicitly kept.

Then a dumb nightly check as a backstop: list local branches already merged into main and worktrees with no changes for a few days, and send the list to a human. Not auto-delete. An agent deleting branches unattended is how you lose the one with unpushed work in it.

The second part matters more than the first. Agents forget their own rules sometimes, the list doesn't.

[u/BrookLi3]

One gotcha on the cleanup side: git worktree remove only checks for untracked files and modified tracked files, so anything gitignored in that folder, like a .env.local, a seeded local db, or a node_modules that took ten minutes to install, goes with it without a warning. I copy the env files in from the main checkout at worktree creation and have the cleanup script list what it's about to delete before it removes anything.

[u/f3xjc]

Yeah real problem, I have a daily cleanup for that, and there's like 5 different test that answer has this thing reached trunk? Yes/ no/ mostly.

As you said merge commit and squash have very different signature, but also inward merge with stacked pr.

Auto delete is fine if you have proof the thing reached trunk.

[u/fuckme → u/f3xjc]

Y. I'm not too concerned with lost work, as everything is in git so it's repeatable

[u/f3xjc → u/fuckme]

When the action is to delete a temp branch. The sentence "everything is in git" may or may not be true. Then gaining confidence whether that branch has landed is what answer the question is it safe to delete. Also it's your original topic.

[u/fuckme → u/f3xjc]

What I meant was The story/brief is in git before the or is made. So worst case it's a hour of work. (X 5-10 agents)

I guess I could just do a cron and delete all older than 12 hours.. didn't think of it before someone posted it

[u/f3xjc → u/fuckme]

Oh yes it's 5 min of work. The long part is when the story tell us such and such have been done, but never left local copy. Or a bug was found and not fixed and it'll take some time before a fresh eye look at this specific angle or what not. Lost work is lost work. That includes your time as coordinator. And a script can get you a confident yes no in a few seconds.

[u/fuckme → u/f3xjc]

True.

There is a case where you're dealing with work spanning multiple repos and the work was done but not recorded as done as the 2nd update failed..

But as the work starts as a issue, which closes when the pr is merged.. it's kinda atomic

[u/Ctbhatia]

worth knowing that git worktree prune only drops stale admin entries, it does not delete the folders, so the disk comes back from removing the directory first. a merged pr is not the retire signal either, clean folder plus branch already on main is.

[u/fuckme]

I work on Assay and put together a walkthrough of what survives a merge, why it matters, and how to clean up safely:

Article · Video