Hey hey, I just discovered that none of my remote ...
# how-do-i
a
Hey hey, I just discovered that none of my remote branches are being removed through (what I think is) normal Graphite workflows of having the merge queue land a PR. Is this by design? Are we supposed to revisit branches to clean them up? My workflow is mostly via CLI, so
gt sync
removes the local branch, making it harder to identify the corresponding remote branch. My team has been using Graphite for a while now so there are over a hundred merge PRs that now have these abandoned branches that need to be closed so doing that manually isn't a quick task. There are also a bunch of "graphite-base/x" branches that I don't recognize, which I guess I need to address too.
✅ 1
p
(If applicable) To help us more clearly understand what you're trying to do, please provide additional details about: - Screenshots / debug logs / list of commands you've tried to run so far - Your workflow - Current state
hey adam, is this on your local or within github?
a
We’re talking remote branches only, all on GitHub. Local cleanup is great
p
after some digging, it looks like this has to be handled by gh 😔 however, i do see a ticket right now where
gtmq_spec_
branches aren't being cleaned up and the team is currently working on this for merge queue.
a
Roger that, thanks for checking. Turned out one of our repos did not have that option checked. There are still closed PRs with the dangling branches, but not so many
So is the gtmq_spec related to the graphite base branches?
p
those are merge queue synthetic branches.
m
@Jocelyn Beaudoin - did this ever get fixed? my repo has a bunch of merge queue branches that are not getting cleaned up automatically.
j
Hey Matt, we’re still tracking this issue and working on a fix. If you can share a few affected PRs from the repo, I’ll link them to the internal issue so the team has concrete examples to reference.
b
We still find orphaned merge queue branches that never get closed. This happens many times a month (example:
gtmq_spec_cf085a_1784669884325-80eb28b6-25bb-40bd-bd5a-8627b81dcd51
). Is there any update here?
j
Hey Bilal, Thanks for the branch name. That
gtmq_spec_cf085a_1784669884325-80eb28b6-25bb-40bd-bd5a-8627b81dcd51
branch looks tied to a merge-queue draft that's already closed on GitHub, while the branch itself is still there. Merge queue is supposed to remove those
gtmq_spec_*
branches after the draft closes, and that cleanup can miss. Could you try one of these: 1. Delete the leftover
gtmq_spec_*
branches you're already seeing as orphans, then refresh the branch list and confirm those names are gone. 2. Or leave them if they're not blocking anything. Nothing else you need to change on your side for the cleanup gap itself.
b
I do periodically do this. But I would consider it a bug that this clutter gets left. It causes noise when I visualize the git log on my CLI and remains a frustrating thing to have to police on our end.
j
Hey Bilal, Totally fair. Those leftover
gtmq_spec_*
branches are a cleanup miss on our side after the merge-queue draft closes. There's nothing more for you to change on your end; I'll pass your note along so the team has the noise/CLI clutter impact.