RE: On-branch topic description support?

[<rsbecker@nexbridge.com>]

On July 21, 2022 11:06 AM, Junio C Hamano wrote:
>Junio C Hamano <gitster@pobox.com> writes:
>
>>  * "git merge" would learn an option to recognize that the branch
>>    being merged has such an empty commit at the tip, and instead
>>    merge the parent of the tip of the branch into the integration
>>    branch, while using the log message of the discarded tip commit
>>    in the log message of the merge itself.
>
>An issue that needs to be worked out at the Porcelain level is that this
layout will
>make "git branch --[no-]merged master", which is an effective way to list
what's in
>and what's left out of the 'master'
>integration branch, more or less useless.  A topic branch with the cover
letter
>commit at the tip may want to be merged to 'next' and then after cooking
for a
>while merged down to 'master', and each time it gets merged, the merge has
to
>leave the cover letter commit alone.  In spirit, such a merge commit merges
the
>topic "fully", but at the topological level, the topic is not (and will
never be)
>merged fully, and "git branch --merged next" will not show.
>
>I guess once the topic hits the oldest integration track that it meant to
go, we
>could "pop" the cover letter commit out of the topic, and at that point it
would
>appear to have been merged to 'master' as well as to 'next'.  But it would
be nice if
>we did not have to discard the cover letter commit only to please "git
branch".
>IOW, it would be helpful to teach "git branch --[no-]merged" to compute the
>"right thing" in such a layout.

I might be missing something here, but could not a description follow
similar semantics to how git describe works on tags? Anchor the description
on the commit where the branch was spawned, then determine the appropriate
description based on things like --first-parent. Again, I'm probably in the
weeds.
--Randall