workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Vegard Nossum <vegard.nossum@oracle.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: Wed, 16 Oct 2019 13:10:09 +0200	[thread overview]
Message-ID: <20191016111009.GE13154@1wt.eu> (raw)
In-Reply-To: <b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com>

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

  reply	other threads:[~2019-10-16 11:10 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 [this message]
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
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=20191016111009.GE13154@1wt.eu \
    --to=w@1wt.eu \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vegard.nossum@oracle.com \
    --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).