Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp7384912ybp; Wed, 16 Oct 2019 07:56:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqzWWd5kA1ctBGVKKyUrdPJimaJ7Cm2BL4YGmL3DtPVpzrMfciS880vJP6Hz/44+XxtmnOht X-Received: by 2002:a17:906:3615:: with SMTP id q21mr39206829ejb.152.1571237770087; Wed, 16 Oct 2019 07:56:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571237770; cv=none; d=google.com; s=arc-20160816; b=idkS4QJB+jbakv3XYmTgH9VoMFq91YtRQCc6tF6dXW+NHjMc2VNFSTLFxbm1GaI5M0 QHhwiGvlIUj2hO/hVoB8ksVyM72Hjf80bwjtpmNKwCs2f3KyRgZgJUeJLE8Uo4jvmuJR TtfoiHq3WC3mJ2CtLhpxl5kLHJFYwZIF3w8KhHT/9FDb+60n0K0KtAJ/oxpkRtmfzh2E l0R+7TK+rGGF7I3/NZrQ2Uoe5y1JLxBSLi5ARb0itJVrcqjHFcxDzJiOs6XXGrlCWEtv ntUGMhbUu3vUi6IEpTD363atK2URWBJ9ikZNFJvVMoD+xbH96pqA4qpCXprKsKHV83pB 4scg== 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=QN6NF/vDN1TpKcj2Y4SoJPzikAo76hqsq7AwgY1P6dQ=; b=EKBZmvquYrzu6DP9VDmehugyp+oYEJNxCRhOyVA3+meyMGIjEGNz/8ogRouAiHNi5Z yBICeTHAtomcBiM+PuLX8E3ydmI671Mto1o6WCW3bzcpAFAdBZV+iTgoBG3zux0zQX2Z BEPxLL9FM1ixUsiZEm9+rWjO6DgmygTvXBW+Fyj+JNbpSqwfp0ODKWbCSV1OxBx5gM5d 9HjvmXNFug7hld/EvGvor0Xgtipr3FbXQJFFL8OeP+SAcL3myOLsAZTZvUY1xb75d/SH 6lydjHiYJWuSWa5M51X8S7py4uOZ31tICI+IHloCESUC3j1tIsFCaviSUQ/1QPAhJ4Iq U74g== 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 t7si15887158ejo.302.2019.10.16.07.55.46; Wed, 16 Oct 2019 07:56:10 -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 S2392616AbfJPLK1 (ORCPT + 99 others); Wed, 16 Oct 2019 07:10:27 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:62450 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730377AbfJPLK0 (ORCPT ); Wed, 16 Oct 2019 07:10:26 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x9GBA9bk013439; Wed, 16 Oct 2019 13:10:09 +0200 Date: Wed, 16 Oct 2019 13:10:09 +0200 From: Willy Tarreau To: Vegard Nossum Cc: workflows@vger.kernel.org, Git Mailing List , LKML , Konstantin Ryabitsev , Eric Wong Subject: Re: email as a bona fide git transport Message-ID: <20191016111009.GE13154@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vegard, On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote: > (cross-posted to git, LKML, and the kernel workflows mailing lists.) > > Hi all, > > I've been following Konstantin Ryabitsev's quest for better development > and communication tools for the kernel [1][2][3], and I would like to > propose a relatively straightforward idea which I think could bring a > lot to the table. > > 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 > > Having these two will allow a perfect mapping between email and git; > essentially email just becomes a transport for git. There are a lot of > advantages to this, particularly that you have a stable way to refer to > a patch or commit (despite it appearing on a mailing list), and there > is no need for "changeset IDs" or whatever, since you can just use the > git SHA1 which is unique, unambiguous, and stable. I agree this would be great and have been missing this a number of times, eventhough I'm aware of git-send-pack/git-receive-pack. The text format is way more convenient for a lot of reasons. It could also help with Greg's idea of using the commit IDs to reference bugs, as such IDs could remain stable within a series before it is merged, and as such referenced in subsequent commit messages. It could also be useful to avoid losing notes related to a patch once it's merged. > Step 3: > > * 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 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.) That's a good idea, as we've all seen long series with a very detailed description in patch 0 and much less context in subsequent patches, thus losing the context once merged. > * stable SHA1s means we can refer to previous versions of a patchset by > SHA1 rather than archive links. I propose a new changelog tag for > this, maybe "Previous:" or maybe even a full list of "v1:", "v2:", > etc. with a SHA1 or ref. Note that these SHA1s do *not* need to exist > in Linus's repo, but those who want can pull those branches from the > bot-maintained repo on git.kernel.org. For me this mainly brings the benefit of finally having a unique identifier for multiple iterations of a patchset. It then becomes easier to use this identifier to designate the functional work, regardless of the number of updates it gets. Of course it's never that black and white since such work may itself merge multiple other patchsets but for most use cases it can help. Willy