RE: On-branch topic description support?

From

rsbecker@nexbridge.com <rsbecker@nexbridge.com>

Date

Jul 21, 2022, 15:29 UTC

Message-ID

<010101d89d16$a97184a0$fc548de0$@nexbridge.com>

In-Reply-To

<xmqq35eumrp8.fsf@gitster.g>

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.