Re: On-branch topic description support?

[Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>]

On 7/21/2022 7:40 AM, Junio C Hamano wrote:
 > I've been playing with this idea from time to time, but recently I
 > started seeing a related discussion on the b4 front, so I thought I
 > would throw it out and how people would think.
 >
 > We made "git merge" not to silently commit the result, but open the
 > editor to encourage the integrator to describe what the topic is
 > about.  We also made "git format-patch" prepare [PATCH 0/n] aka
 > "cover letter" so that the author of the patch series can express
 > what the overall topic is about.  What the author should say in the
 > cover letter very much overlaps what the integrator wants to have in
 > the log message of the commit that merges the topic to the
 > integration branch.
 >
 > But there are two (and half) links from format-patch to that merge
 > commit that are missing.
 >
 >  - You cannot prepare the cover letter material while working on the
 >    topic---instead, you have to write one by editing the output from
 >    "format-patch --cover-letter";

This bothered me for a long time. Across every "rebase -i", I could see
a chance to modify the cover letter, but only right before sending the
patch I got the chance to compose a summary of what I've done in the
series, and that often makes me forget about things that should be in
the cover letter. And I have to keep a draft somewhere to record the loose
thoughts along the way.

 >  - "git am" at the receiving end discards the cover letter when
 >    queuing the e-mailed patches to a topic.
 >
 >  - "git merge" cannot take advantage of the cover letter that was
 >    discarded when the topic was queued.
 >
 > So, here is how I would imagine a slightly better world may work.
 >
 >  * When you are almost finished with the initial draft of your
 >    topic, you'd write a cover letter, and record it as the log
 >    message of an empty commit at the tip of the topic.  As you go on
 >    polishing the topic with "rebase -i", the empty commit would be
 >    kept (if we currently lose an empty commit by default, we may
 >    need to teach "rebase -i" to special case an empty commit at the
 >    tip of the range to make this convenient to use), and you would
 >    keep it up to date as you update the topic.
 >
 >  * "git format-patch" would notice that the topic has such an empty
 >    commit at the tip, and use the log message from it to
 >    pre-populate the cover letter.

It sounds pretty neat to have this on-the-go topic recorder :-)

--
Thanks,
Shaoxuan