workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vegard Nossum <vegard.nossum@oracle.com>
To: Junio C Hamano <gitster@pobox.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 15:30:54 +0200	[thread overview]
Message-ID: <9ec63ec0-c322-610c-e1b8-b673b983dc74@oracle.com> (raw)
In-Reply-To: <xmqqeezc83i6.fsf@gitster-ct.c.googlers.com>

On 10/17/19 5:17 AM, Junio C Hamano wrote:
> 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.

Please see what I wrote to Pratyush Yadav here:

https://public-inbox.org/git/a1c33600-14e6-be37-c026-8d8b8e4bad92@oracle.com/

TL;DR: the goal is not necessarily for maintainers to be able to merge
the patchset with the same SHA1 that the submitter had, but for the
patchset to have a definite SHA1 that lives in git, and which can be
used by all the participants -- submitter, reviewers, bots (including
potentially testing/CI infrastructure), and maintainers.

I am definitely not proposing to get rid of the email workflow -- on the
contrary, this it the workflow I want to preserve! :-) The "workflows"
mailing list was created for the purpose of discussing this topic (in
the context of Linux kernel development) and right now there are many
proposals that either completely cut out email or reduce it to something
like pull requests. My proposal keeps almost everything the same, except
for a few lines of extra metadata before the actual diff.

(I will answer the rest of your email separately.)


Vegard

  reply	other threads:[~2019-10-17 13:33 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
2019-10-17 13:30   ` Vegard Nossum [this message]
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=9ec63ec0-c322-610c-e1b8-b673b983dc74@oracle.com \
    --to=vegard.nossum@oracle.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).