linux-kernel - Re: email as a bona fide git transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ec63ec0-c322-610c-e1b8-b673b983dc74@oracle.com>
Date:   Thu, 17 Oct 2019 15:30:54 +0200
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     Junio C Hamano <gitster@...ox.com>
Cc:     workflows@...r.kernel.org, Git Mailing List <git@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Eric Wong <e@...24.org>
Subject: Re: email as a bona fide git transport

On 10/17/19 5:17 AM, Junio C Hamano wrote:
> Vegard Nossum <vegard.nossum@...cle.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