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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 16, 2023, 22:35 UTC
Message-ID: <xmqq1qmpp7bh.fsf@gitster.g>
In-Reply-To: <20230216193210.6yj24zhhdhoozpr3@carbon>

Konstantin Khomoutov <kostix@bswap.ru> writes:

Show 15 quoted lines

> 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.