Re: [PATCH v9 3/5] branch: add --prune-merged <remote>

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

Phillip Wood <phillip.wood123@gmail.com> writes:

> I think being able to prune branches that have been merged into their 
> upstream is a good idea. However, I find the focus on remotes rather 
> than upstream branches in the UI a bit confusing. While the upstream of 
> a branch is often a remote tracking branch it doesn't have to be. For my 
> personal projects I often do
>
> 	git checkout -b topic master
>
> and it would be nice to be able to run
>
> 	git branch --prune-merged master
>
> to clean up those topics that have been merged.

Excellent suggestion.

The task at hand is to make a list of things that "track" (in the
"checkout -t" sense) something, see which one in that list are
descendant of that something, and removing those that have already
been merged into that something.  There is nothing that requires
that something to be a remote-tracking branch at all.

If

    git branch --forked master

(i.e., "who tracks 'master' in the 'checkout -t' sense") were
available, then

    git branch --merged master | sort >1
    git branch --forked master | sort >2
    comm -12 1 2

would give us the list of branches that forked from 'master' and
have already been merged, i.e., candidate to be removed via the
"prune-merged" mechanism.  With the built-in "git branch -d"
protection to require capital "-D" to force removal of a new work
that is not merged to tracked, we actually need only 

    git branch --forked master |
    xargs git branch -d

to do so.  We may want to give --dry-run to "git branch -d" so that
you can say

    git branch --forked master |
    xargs git branch -d --dry-run

to see what would be removed.

And again, there is no strong reason why "--forked" has to work only
with remote-tracking branches.

> Similarly I think it is 
> confusing that
>
> 	git checkout -b topic origin
>
> starts a branch from the default branch on origin, but if I run
>
> 	git branch --prune-merged origin

Sorry, this was my bad.  I agree that it is not a useful thing for
"origin" to mean "origin/*" here when it is established that
"origin" to mean "origin/HEAD".