git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Vegard Nossum <vegard.nossum@oracle.com>
To: Pratyush Yadav <me@yadavpratyush.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: Thu, 17 Oct 2019 14:23:58 +0200	[thread overview]
Message-ID: <a1c33600-14e6-be37-c026-8d8b8e4bad92@oracle.com> (raw)
In-Reply-To: <20191016150020.cr6jgfpd2c6fyg7t@yadavpratyush.com>


On 10/16/19 5:00 PM, Pratyush Yadav wrote:
> On 16/10/19 12:22PM, Vegard Nossum wrote:
> Just to play the devil's advocate, even though I'm in favor of something
> like this, I'll add in another disadvantage:
> 
> - The maintainer can't make small edits before pushing the changes out.
> 
> I do that every now and then for git-gui, and Junio does that sometimes
> for Git. I don't know if the folks over at Linux do something like this,
> but using '--exact' would mean that contributors would have to send a
> re-roll for even minor changes. Its mostly an inconvenience instead of a
> problem, but I thought I'd point it out.

I don't think this is a problem.

The point of 'git am --exact' is not for maintainers per se (although
they should use it if they don't have any manual changes to make), but
for the bot that keeps track of patchsets submitted via email.

The important part is that there is a git reference to the patchset that
was submitted in the patchset that was merged. You could see it as the
maintainer rolling a new version of the patchset locally and merging
that instead of merging what was submitted directly.

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.

> One more question, not strictly related to your proposal: right now,
> when I apply patches from contributors, I pass '-s' to 'am', so the
> applied commit would have my sign-off. The way I see it, that sign-off
> is supposed to signify that I have the right to push out the commit to
> the "main" repo, just like the author's sign-off means that they have
> the right to send me that commit.
> 
> Looking at git.git, I notice that Junio does the same. The new '--exact'
> would be incompatible with '-s', correct (since the commit message has
> changed, the SHA1 would also change)? So firstly, make sure you account
> for something like that if you haven't already (I haven't found the time
> to read your patches yet). Secondly, is it all right for the maintainer
> to just not sign-off on the commits they push out?

In the Linux kernel at least, only the front-line maintainers add their
signoffs; higher-level maintainers take pull requests and don't add
their own sign-offs. Only Linus (and Greg, perhaps) has commit rights to
the main repository, but he only signs off on the patches that he either
writes himself or applies directly from email.

In any case, I don't think this is a concern because of what I wrote
above -- somebody who wants to add their signoff can do it by
essentially rolling a new version of the patchset that has the signoff,
but refers to the sha1 that was submitted to them by the patchset author
so that you can still find the original commits (without the signoffs)
and reviews/discussions.

I don't want to create extra work for maintainers, so I think any
solution should involve having the existing git tools/workflows do the
right thing automatically.

How about this? If 'git am' or 'git am -s' (without --exact) finds an
email patch where the exact commit metadata is present, it automatically
appends a line to the changelog saying where it was taken from:

     Submitted-as: 111122223333444455556666777788889999aaaa

or

     Applied-from: 111122223333444455556666777788889999aaaa

Although, again, this would modify the changelog of the patch itself
rather than just the changelog of the merge commit... Maybe this is
enough and we can have the "patchset" command also add references to
previous versions of each patch rather than the patchset as a whole.


Vegard

  reply	other threads:[~2019-10-17 12:24 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
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 [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1c33600-14e6-be37-c026-8d8b8e4bad92@oracle.com \
    --to=vegard.nossum@oracle.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@yadavpratyush.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).