Subject: Re: [PATCH v8 0/5] branch: prune-merged

From: Junio C Hamano <[email-masked]>
Date: Wed, 13 May 2026 22:46:27 +0900

"Harald Nordgren via GitGitGadget" <[email-masked]> writes:

>      +    Delete the local branches that --forked <remote> would list, but
>      +    only those whose tip is reachable from their configured upstream
>      +    remote-tracking branch (branch.<name>.merge): the work has already
>      +    landed on the upstream it tracks, so the local copy is no longer
>      +    needed.
>      +
>      +    A branch whose upstream no longer resolves locally is left alone --
>      +    its disappearance is not, on its own, evidence that the work was
>      +    integrated.

That matches my understanding of the original motivation of this
topic a lot better than the previous round.

>      +    integrated. With --force, skip the reachability check and delete
>      +    every branch in the candidate set.

I am not sure if this is a good idea at all.  The option is called
prune-MERGED and with or without --force, mergedness should be what
determines if a branch is deleted.

To perform an equivalent of

	$ git branch -D $(git branch --forked <remote>)

it would be better not to (ab)use the more commonly useful and much
safer "--prune-merged", and let's not add "--prune-forked" either as
a short-cut.  A nuclear option should be made harder to trigger, ot
easier to trigger by confusion between "--prune-{merged,forked}".