From: Shaoxuan Yuan Date: Thu, 21 Jul 2022 00:52:59 GMT Subject: Re: On-branch topic description support? Message-ID: In-Reply-To: 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