On Thu, Feb 16, 2023 at 08:12:08PM -0700, Alex Henrie wrote: > > >> GitHub and GitLab have features to create a branch using the web > > >> interface, then delete the branch after it is merged. That results in a > > >> lot of "gone" branches in my local clone, and I frequently find myself > > >> typing `git branch -v | grep gone`. I don't want `git branch --merged` > > >> because that would include branches that have been created for future > > >> work but do not yet have any commits. > > > > > > Possibly a rather silly remark, but you could make a habit of periodically > > > running > > > > > > git remote prune <remotename> > > > > > > or fetching with "--prune". > > > > Likely to be a silly question, but isn't doing that, to actively > > remove the remote tracking branches that correspond to branches that > > no longer exist at the remote, exactly what gives Alex many local > > branches that are marked as "gone" (i.e. forked from some upstream > > sometime in the past, but the upstream no longer exists)? > > Yes, the branches are marked [gone] precisely because I configured > fetch.prune to true. So fetching automatically deletes the local > copies of the upstream branches, but the local branches that track > them are still there. Ah, thanks, I see now. I have a habit of always checking out remote branches directly when doing any work on them (they end up in a detached HEAD state), so I have sort of automagically evaded your problem not being aware of the fact.
