git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: On-branch topic description support?
Date: Wed, 20 Jul 2022 16:40:52 -0700	[thread overview]
Message-ID: <xmqqilnr1hff.fsf@gitster.g> (raw)

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";

 - "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.

 * "git am" would learn an option to save the cover letter [0/n] and
   create such an empty commit at the tip of the branch.

 * "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.

Yes, there is "git config branch.mytopic.description" that helps
when pre-populating the cover letter, but that only helps at the
origin, and it is not shared between your personal repositories.
If you have the draft of the cover letter as part of the branch,
you can push/fetch them around just like all the "real" commits
you are working on.

Regardless of where the cover letter comes from, the changes to "am"
and "merge" dreamed above in this message would be useful, and that
is the primary reason why I am envisioning that right at the origin
having the topic description as an empty commit at the tip would be
the most convenient.  It would match the shape of the history at the
author side and at the side who runs "git am".

             reply	other threads:[~2022-07-20 23:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 23:40 Junio C Hamano [this message]
2022-07-21  0:52 ` On-branch topic description support? Shaoxuan Yuan
2022-07-21  5:25 ` Elijah Newren
2022-07-21  6:11   ` Junio C Hamano
2022-07-21 14:41   ` Konstantin Ryabitsev
2022-07-21 16:06   ` Philip Oakley
2022-07-21 17:29     ` Junio C Hamano
2022-07-21 14:53 ` Ævar Arnfjörð Bjarmason
2022-07-21 16:26   ` Konstantin Ryabitsev
2022-07-21 17:35     ` Junio C Hamano
2022-07-21 17:51       ` Ævar Arnfjörð Bjarmason
2022-07-21 17:16   ` Junio C Hamano
2022-07-21 17:49     ` Ævar Arnfjörð Bjarmason
2022-07-21 18:02       ` Junio C Hamano
2022-07-21 18:26         ` Konstantin Ryabitsev
2022-07-21 18:58           ` Ævar Arnfjörð Bjarmason
2022-07-21 19:13           ` Konstantin Ryabitsev
2022-07-21 20:01             ` Junio C Hamano
2022-07-21 20:19               ` Konstantin Ryabitsev
2022-07-21 20:48                 ` Junio C Hamano
2022-07-21 15:05 ` Junio C Hamano
2022-07-21 15:29   ` rsbecker
2022-07-21 15:39     ` Konstantin Ryabitsev
2022-07-21 15:57       ` rsbecker
2022-07-22  3:15 ` Bagas Sanjaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqilnr1hff.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).