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

[Junio C Hamano <gitster@pobox.com>]

Konstantin Khomoutov <kostix@bswap.ru> writes:

> Alex Henrie <alexhenrie24@gmail.com> writes:
>
>> 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)?

> At my $dayjob, we use GitLab, and I routinely fetch with "--prune" because
> most of the time there's no sense in seeing stale (merged in and deleted)
> branches, and if it's really needed, their then-tips can be figured out from
> the merged commits which have integrated those branches.

Yes, as a workflow, it may make sense to aggressively prune remote
tracking branches (especially if you have good backups). But I think
the feature is more about the local branches you grow with your
commits, and not about the local copies of remote branches that went
stale.

If local topic Y forked from a remote topic X, depended on what X
did, and after a while X graduated to the primary integration branch
'main' and removed at the remote, after pulling the updated 'main',
your 'log main..Y' would still exclude the work done in 'X' and show
only your work on topic 'Y'.  You could rebase 'Y' on 'main' if you
wanted to (but I strongly discourage people from doing so in _this_
project) and a tool to see which local topics like Y lost the base X
that was work-in-progress would be a way to find which ones to rebase.