workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Vegard Nossum <vegard.nossum@oracle.com>
Cc: workflows@vger.kernel.org, Git Mailing List <git@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Eric Wong <e@80x24.org>
Subject: Re: email as a bona fide git transport
Date: Thu, 17 Oct 2019 12:17:21 +0900	[thread overview]
Message-ID: <xmqqeezc83i6.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com> (Vegard Nossum's message of "Wed, 16 Oct 2019 12:22:54 +0200")

Vegard Nossum <vegard.nossum@oracle.com> writes:

> Step 1:
>
> * git send-email needs to include parent SHA1s and generally all the
>   information needed to perfectly recreate the commit when applied so
>   that all the SHA1s remain the same
>
> * git am (or an alternative command) needs to recreate the commit
>   perfectly when applied, including applying it to the correct parent

You can record and convey the commit object name a series is meant
to be applied on top already, and it in general is a good way to
give a wider context in order to explain and justify the series.

On the other hand, "all the information needed to recreate..." is
not very useful.  If you want the commit object to be exactly what
you want to see at the tip of the end result, you are better off
asking your upstream to pull.  Using e-mail for that makes you and
project participants give up a lot of benefits the workflow based on
e-mail gives you, the biggest of which is the ease of giving
suggestions for improvements.  Once you insist "perfectly recreate
the commit", you are not willing to take any input from the
sidelines---worse yet, you are even dictating when the upstream
runs "git am" to turn them into commits, and do so without reading
the patches (there is no point reviewing as the person who runs "git
am" is not even allowed to fix typo or make obvious fixes to the
code, which will fail to perfectly recreate the commit).

In short, one should resist temptation to bring up "perfect
reproduction" when one talks about e-mail workflow.

> * Instead of describing a patchset in a separate introduction email, we
>   can create a merge commit between the parent of the first commit in
>   the series and the last and put the patchset description in the merge
>   commit [5]. This means the patchset description also gets to be part
>   of git history.

This has been done with tools around git-core, and merits a more
official support.  When merging a topic, it is a good idea to
explain in the merge commit that brings in the topic to the mainline
what the topic is about, and at least in the past few years Linus
and other maintainers both within and outside the kernel have been
doing so.  The cover-letter material in [PATCH 00/NN] obviously can
help those integrators when they write the merge message.

>   (This would require support for git send-email/am to be able to send
>   and apply merge commits -- at least those which have the same tree as
>   one of the parents. This is _not_ yet supported in my proposed git
>   patches.)

This does not require much from format-patch and am.  All you need
to do is to ensure that they can handle an empty commit.  What you
need more is a support in merge.  The outline for the workflow would
go like this:

 * The contributor prepares an N patch series 1/N..N/N on a single
   topic branch.

 * The summary of the series, the message that is meant to help the
   integrator, is recorded as (N+1)th commit at the tip of the topic
   branch, as an empty commit (i.e. a commit that records the same
   tree as its parent).

 * "git format-patch" is taught, when told to prepare the patch
   e-mails from such a topic branch, to notice the unusual "an empty
   commit at the tip" layout, and turn that into 0/N of the message.

 * "git am" is taught a new option to cap a topic branch made from
   patches 1/N..N/N from the incoming mbox with an extra empty
   commit, whose message is taken from the 0/N cover-letter
   material, to recreate what the contributor had in the second step
   above.

 * "git merge" is taught, when told to merge a topic branch, to
   notice the unusual "an empty commit at the tip" layout, and

   (1) merge topic~1 instead to excise the empty commit itself,

   (2) take the log message from the empty commit at the tip and use
       it to help prepare the log message of the merge.


  parent reply	other threads:[~2019-10-17  3:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 10:22 email as a bona fide git transport Vegard Nossum
2019-10-16 11:10 ` Willy Tarreau
2019-10-16 14:45   ` Santiago Torres Arias
2019-10-17 20:43     ` Greg KH
2019-10-17 20:45       ` Konstantin Ryabitsev
2019-10-18  1:30         ` Greg KH
2019-10-18  1:54           ` Konstantin Ryabitsev
2019-10-18  2:52             ` Willy Tarreau
2019-10-18  6:34               ` Nicolas Belouin
2019-10-18 15:50                 ` Santiago Torres Arias
2019-10-20  5:50           ` Laurent Pinchart
2019-10-18 14:27     ` Vegard Nossum
2019-10-18 15:54       ` Santiago Torres Arias
2019-10-18 16:03         ` Konstantin Ryabitsev
2019-10-18 16:11           ` Santiago Torres Arias
2019-10-18 18:00             ` Konstantin Ryabitsev
2019-10-18 16:15       ` Theodore Y. Ts'o
2019-10-18 16:50         ` Vegard Nossum
2019-10-18 19:14           ` Theodore Y. Ts'o
2019-10-20  3:17             ` Willy Tarreau
2019-10-20  6:28               ` Vegard Nossum
2019-10-22 12:11                 ` Vegard Nossum
2019-10-22 13:53                   ` Theodore Y. Ts'o
2019-10-22 16:29                     ` Vegard Nossum
2019-10-22 19:01                   ` Eric Wong
2019-10-16 15:00 ` Pratyush Yadav
2019-10-17 12:23   ` Vegard Nossum
2019-10-17 13:11     ` Theodore Y. Ts'o
2019-10-17 14:01       ` Vegard Nossum
2019-10-17 14:47         ` Theodore Y. Ts'o
2019-10-17 15:11         ` Steven Rostedt
2019-10-16 20:57 ` Jonathan Nieder
2019-10-17 13:08   ` Vegard Nossum
2019-10-17  3:17 ` Junio C Hamano [this message]
2019-10-17 13:30   ` Vegard Nossum
2019-10-18  2:22 ` Eric Wong

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=xmqqeezc83i6.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vegard.nossum@oracle.com \
    --cc=workflows@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).