Re: [PATCH] branch: introduce --(no-)has-upstream and --(no-)gone options

[Konstantin Khomoutov <kostix@bswap.ru>]

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.