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

[Phillip Wood <phillip.wood123@gmail.com>]

On 18/06/2026 17:08, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> One thing I've just thought of related to this patch is whether we want
>> to protect branches that are the upstreams of branches that are not
>> slated for deletion. With stacked branches it is possible that a branch
>> has been merged but has other branches stacked on top of it that have
>> not been merged.
> 
> An interesting point.  We do have "this topic is built on the result
> of merging these other topics into main" and I expect the practice
> is wide spread.  These base topics may graduate first, but other
> topics may still be updated.
> 
> But when you rewrite these other topics, wouldn't you leave their
> bases untouched?  IOW, a new iteration (i.e. "rebase -i") would
> reuse the base that was used in an earlier iteration, i.e. the
> result of an earlier merge of the other topics, some of which might
> have been pruned since then, into an older 'main', so it is OK to
> lose these other topics once they have graduated, simply because you
> wouldn't be recreating the merge that you used as the base of this
> remaining topic, no?
> 
> Or am I missing something?

I was thinking that if I have feature1 with upstream origin/master and 
feature2 with upstream feautre1, then once feature1 is merged I'd still 
like "git log @{u}.." and "git rebase" without an explicit upstream to 
work when feature2 is checked out. If "git branch --prune-merged 
origin/master" deletes feautre1 then those commands stop working. Maybe 
it would be sensible to update feature2's upstream once feature1 is 
merged (which I think is what you're saying above) but do we really want 
to force the user to do that by deleting feature1?

Thanks

Phillip