Re: [PATCH v14 4/6] branch: add --prune-merged <branch>

On 19/06/2026 17:01, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

  - Notice that a branch that is deleted (because it itself is
    merged) is still depended upon by being @{upstream} of somebody
    else, and when it happens, fail the operation (i.e., do not
    delete the branch).

Not deleting is definitely the safest option. As Harald has pointed out 
we then need to think about what to do with the upstream branch of the 
branch we're keeping because it is an upstream of another branch that's 
not being deleted. Keeping the whole chain is probably safest.

What are the viable choices we can offer to the user in such a
situation?  I think there are a few viable choices.

  - Make the dependent branch no longer depend on anything.  Asking
    feature2@{upstream} would fail.

  - Move the @{upstream} of feature2 to the branch that "merged"
    feature1 and caused its removal.  Asking feature2@{upstream}
    would answer origin/master, which feature1 was removed after
    getting merged.

The second option is quite tempting. My only concern about doing it 
automatically is that it would break "git rebase --fork-point" (which is 
the default if you don't specify an upstream). If a user rewrites a 
branch, merges it and then "git branch --delete-merged" deletes it and 
reassigns the upstream of the branches descended from it, rebasing those 
branches would pull in some stale commits.

There may be others.  And there may be relationship similar to
feature1 vs feature2 that is not @{upstream} but something else that
makes a branch still "depend on" the other branch getting deleted.

Do we also need the same safety around "git branch -d feature1" by
the way?  The "-d" option with safety checks the same "is feature1
already merged (to its upstream)?" condition, so it can protect the
feature2 branch the same way, by saying either "oops, you cannot
delete feature1 because you still have other branches like feature2
that depend on it", or "ok, featur2 used to depend on feature1, but
because we are deleting feature1 based on it being in origin/master,
we will make feature2 depend on origin/master from now on".

I think handling branches that are the upstream for another branch the 
same way for "git branch -d" and "git branch --prune-merged" is a good idea.

Thanks

Phillip