Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp903375ybg; Fri, 18 Oct 2019 09:03:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqzw23VGlD8QpisAbgEL4dZwS5g96dBTs+kM3OHzfZ1CImkj65lEZA8gWTrAh+rVYyPddsh/ X-Received: by 2002:aa7:d842:: with SMTP id f2mr10431693eds.27.1571414618529; Fri, 18 Oct 2019 09:03:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571414618; cv=none; d=google.com; s=arc-20160816; b=TVJLiMzYckKQSqGmjoRv2QO8gwO9oomUm2zfpXR0zjNHBlVA6bTMV8Y9BZSjf8ZYX5 TXe3GAE/Lj3MPhr/0R6cOJ8TU1dNUDtVcVB97pVprRh6CdqAtkGfgSKl0CKC8P2rg5+Q njGI8+YS3KIlmWZzVg3DTzH/Zp5I5IxkCRnybyIKXzwH8rBk9KFtv5jl0OP/6MzijrWv wgKHR86vSqOVNroSyjati9GTzssoAW67JOkll5/CntZUr5qYrw6E6si4hOnH8tfQojYI hBRrNlWEkr+vJ/b88lQco8yQj5yCMGLt9R2NpGTnXKof9pYSxTnp4xhWlnQYFH/ZlR3p porg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Rd7tDM2thnkOCKSPG5IeiyQx/KfW6Snp9IA6ZrjsFN8=; b=V7XCtn+fEz+ZV2YAw5YR6OD5VchzvClDKVvWqwlaY2DTPQpjv5Dc9hTjl7+vOAAPT8 WAdHaFTperFGdEgF0QFAUf61bFX6CdSexjPZyqyeh1UjTYsgqTxGki5TAI1Q+K16joAM hKz5WS3fYQdVgQfcjnjqHoyWZpa9MlbgL5OK0rKGP2bnDc4Cgo+mwyt3W/Br4V82cwE7 /2zW3NoOhvP0MwgBGCZfd3LCw7CZuSVIcDOBLL63YbQR/8kq3Wy1FgRpFCJAlx754jNo 5v/wlDb5IU8P0zIyrILv+79JEE2Oa9Sbp8MAwI3s23R0CjRG/Z+RoijGxB2tRXBLerNt nVAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z54si4295361edd.337.2019.10.18.09.03.15; Fri, 18 Oct 2019 09:03:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394324AbfJQNL5 (ORCPT + 99 others); Thu, 17 Oct 2019 09:11:57 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:36897 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726898AbfJQNL5 (ORCPT ); Thu, 17 Oct 2019 09:11:57 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9HDBe3l008991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Oct 2019 09:11:41 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 977A6420458; Thu, 17 Oct 2019 09:11:40 -0400 (EDT) Date: Thu, 17 Oct 2019 09:11:40 -0400 From: "Theodore Y. Ts'o" To: Vegard Nossum Cc: Pratyush Yadav , workflows@vger.kernel.org, Git Mailing List , LKML , Konstantin Ryabitsev , Eric Wong Subject: Re: email as a bona fide git transport Message-ID: <20191017131140.GG25548@mit.edu> References: <20191016150020.cr6jgfpd2c6fyg7t@yadavpratyush.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote: > Of course, this relies strongly on actually having (correct) sha1 > references to previous versions inside the changelog. In my original > idea, this reference would only appear inside the merge commit that > binds the patchset together to minimise churn, although maybe it is > feasible to also append it to each patch -- in that case, the "patchset" > command from my first email is not sufficient to create a new version of > a patchset. This also relies on the base of the commit actually being a public SHA1. Sometimes developers will cherry-pick in a patch that they need so that the kernel will actually *boot* (or otherwise fix problems that have been fixed in other subsystems, but not yet landed in -rc2 or -rc3). Of course, we could tell people that they should always create their patches off of the last stable version (but then there may have been changes pulled in via the last merge window that makes their patch not apply), or they could be told to develop against -rc2 or -rc3, and then cherry pick the required fix-up patches on top of -rc2 and -rc3, but then they have to do a lot more rebuilding. So there are no perfect solutions here, and while in the ideal world, -rc2 and -rc3 should be perfectly stable enough for developers so that they never need to manually patch in stablization patches, we need to live in the real world. I believe that Darrick told me that in the previous development cycle, he had to wait until -rc4 before the tree was stable enough for him to start building xfs patches on top mainline. (This is also true for this development cycle if you enable CONFIG_KMEMLEAK, although fortunately, the workaround that worked for me was to just CONFIG_KMEMLEAK --- although of course, if I do have to run a KMEMLEAK test run, I'll need to cherry-pick the fix which landed this week on top of the ext4 git tree.) What this all might mean is that sometimes it will make sense to allow the user to override the base commit so such stablization patches can be elided. Of course, we could force the user to create a separate branch and rebase, but can be quite painful and slow --- and they won't be able to test the rebased branch anyway, unless we then want to tell them to cherry pick the stablization patches on top, and then remove them before running "git send-email". - Ted