Message-ID: <1457516710.118898.188.camel@infradead.org>
Date:	Wed, 09 Mar 2016 09:45:10 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org
Cc:	Randy Dunlap <rdunlap@...radead.org>,
	Laszlo Ersek <lersek@...hat.com>
Subject: Re: [PATCH 2/7] Docs: Bring SubmittingPatches more into the git era

On Tue, 2014-12-23 at 09:32 -0700, Jonathan Corbet wrote:
>  
> -16) Sending "git pull" requests  (from Linus emails)
> +16) Sending "git pull" requests
> +-------------------------------
> +
> +If you have a series of patches, it may be most convenient to have the
> +maintainer pull them directly into the subsystem repository with a
> +"git pull" operation.  Note, however, that pulling patches from a developer
> +requires a higher degree of trust than taking patches from a mailing list.

This isn't really true, is it?

If I accept a stream of patches in email, or if I accept them in a pull
request, I can — and should — still actually *look* at what's being
applied before I push it back out again.

In email I should never take someone's word that v7 of a given patch
set, with accrued Reviewed-by: tags from the previous 6 rounds of the
submission, hasn't introduced a trojan horse or done something else
stupid. There's absolutely *nothing* that's more fundamentally
trustworthy about email vs. 'git pull', is there? You can't even trust
that the version in your mailbox is the same as the one that was sent
to the list :)

So why would it ever be safer to blindly save a patch series and apply
it with 'git am', than it is to pull the same?

Either you *look* what what you merge, or you don't.

So I don't really understand the 'higher degree of trust' comment.
Perhaps that was true in the days before git-am. But now that you can
save a whole set of emails and just apply them all with one command
that's as easy as a pull, there isn't really any difference, is there?
Neither tool actually *forces* you to look at what you're merging.

The main reason for preferring email over pull requests, as I
understand it, is probably just to ensure that Reviewed-by: and other
tags can be applied at the time it's committed.

So perhaps something like this...?

iff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index d603fa0..c8f7f9c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -737,10 +737,11 @@ the cover email text) to link to an earlier version of the patch series.
 
 If you have a series of patches, it may be most convenient to have the
 maintainer pull them directly into the subsystem repository with a
-"git pull" operation.  Note, however, that pulling patches from a developer
-requires a higher degree of trust than taking patches from a mailing list.
-As a result, many subsystem maintainers are reluctant to take pull
-requests, especially from new, unknown developers.  If in doubt you can use
+"git pull" operation.  Note, however, that commits should be considered
+immutable as soon as they are visible in public, and this means that
+additional tags such as Reviewed-by: and Tested-by: cannot be included.
+For this reason, some subsystem maintainers are reluctant to take pull
+requests; especially from new, unknown developers.  If in doubt you can use
 the pull request as the cover letter for a normal posting of the patch
 series, giving the maintainer the option of using either.
 
-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)

Powered by blists - more mailing lists