From: Jeff King <peff@peff.net>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: berrange@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org,
Greg Kurz <groug@kaod.org>, Ian Kelling <iank@fsf.org>,
dgilbert@redhat.com, antonios.motakis@huawei.com,
git@vger.kernel.org
Subject: Re: git format.from (was: 9p: Fix file ID collisions)
Date: Tue, 24 Sep 2019 17:36:38 -0400 [thread overview]
Message-ID: <20190924213638.GE20858@sigill.intra.peff.net> (raw)
In-Reply-To: <3312839.Zbq2WQg2AT@silver>
On Tue, Sep 24, 2019 at 11:03:38AM +0200, Christian Schoenebeck wrote:
> > Yes, the resulting mail would be correct, in the sense that it could be
> > applied just fine by git-am. But I think it would be uglier. IOW, I
> > consider the presence of the in-body From to be a clue that something
> > interesting is going on (like forwarding somebody else's patch). So from
> > my perspective, it would just be useless noise. Other communities may
> > have different opinions, though (I think I have seen some kernel folks
> > always including all of the possible in-body headers, including Date).
> > But it seems like it makes sense to keep both possibilities.
>
> Exactly, current git behaviour is solely "prettier" (at first thought only
> though), but does not address anything useful in real life.
I wouldn't agree with that. By being pretty, it also is functionally
more useful (I can tell at a glance whether somebody is sending a patch
from another author).
> Current git behaviour does cause real life problems though: Many email lists
> are munging emails of patch senders whose domain is configured for requiring
> domain's emails being DKIM signed and/or being subject to SPF rules (a.k.a
> DMARC). So original sender's From: header is then automatically replaced by an
> alias (by e.g. mailman): https://en.wikipedia.org/wiki/DMARC#From:_rewriting
>
> For instance the email header:
>
> From: "Bob Bold" <bold@foo.com>
>
> is automatically replaced by lists by something like
>
> From: "Bob Bold via Somelist" <somelist@gnu.org>
>
> And since git currently always drops the From: line from the email's body if
> sender == author, as a consequence maintainers applying patches from such
> lists, always need to rewrite git history subsequently and have to replace
> patch author's identity manually for each commit to have their correct, real
> email address and real name in git history instead of something like
> "Bob Bold via Somelist" <somelist@gnu.org>
>
> So what do you find "uglier"? I prefer key info not being lost as default
> behaviour. :-)
Sure, for your list that munges From headers, always including an
in-body From is way better. But for those of us _not_ on such lists, I'd
much prefer not to force the in-body version on them.
-Peff
next prev parent reply other threads:[~2019-09-24 22:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 19:53 [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-08-22 19:28 ` [Qemu-devel] [PATCH v6 1/4] 9p: Treat multiple devices on one export as an error Christian Schoenebeck via Qemu-devel
2019-08-29 16:27 ` Greg Kurz
2019-09-01 17:38 ` Christian Schoenebeck via Qemu-devel
2019-08-22 19:33 ` [Qemu-devel] [PATCH v6 2/4] 9p: Added virtfs option 'multidevs=remap|forbid|warn' Christian Schoenebeck via Qemu-devel
2019-08-29 16:55 ` Greg Kurz
2019-09-01 18:40 ` Christian Schoenebeck via Qemu-devel
2019-09-02 10:16 ` Greg Kurz
2019-09-02 21:07 ` Christian Schoenebeck via Qemu-devel
2019-08-30 12:22 ` Greg Kurz
2019-09-01 18:56 ` Christian Schoenebeck via Qemu-devel
2019-09-02 11:49 ` Greg Kurz
2019-09-02 21:25 ` Christian Schoenebeck via Qemu-devel
2019-08-22 19:44 ` [Qemu-devel] [PATCH v6 3/4] 9p: stat_to_qid: implement slow path Christian Schoenebeck via Qemu-devel
2019-08-22 19:49 ` [Qemu-devel] [PATCH v6 4/4] 9p: Use variable length suffixes for inode remapping Christian Schoenebeck via Qemu-devel
2019-08-22 22:18 ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions no-reply
2019-08-29 17:02 ` Greg Kurz
2019-09-01 19:28 ` Christian Schoenebeck via Qemu-devel
2019-09-02 15:34 ` Greg Kurz
2019-09-02 22:29 ` Christian Schoenebeck via Qemu-devel
2019-09-03 19:11 ` [Qemu-devel] DMARC/DKIM and qemu-devel list settings Ian Kelling
2019-09-04 8:13 ` Daniel P. Berrangé
2019-09-04 14:19 ` Ian Kelling
2019-09-04 14:30 ` Peter Maydell
2019-09-09 11:47 ` Markus Armbruster
2019-09-10 7:23 ` Stefan Hajnoczi
2019-09-03 19:38 ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Eric Blake
2019-09-04 13:02 ` Christian Schoenebeck via Qemu-devel
2019-09-05 12:25 ` Christian Schoenebeck via Qemu-devel
2019-09-05 12:59 ` Greg Kurz
2019-09-23 11:27 ` Christian Schoenebeck via
2019-09-09 14:05 ` Eric Blake
2019-09-09 14:25 ` Jeff King
2019-09-23 11:19 ` Christian Schoenebeck via
2019-09-23 22:24 ` Jeff King
2019-09-24 9:03 ` git format.from (was: 9p: Fix file ID collisions) Christian Schoenebeck via
2019-09-24 21:36 ` Jeff King [this message]
2019-09-09 18:41 ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Junio C Hamano
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=20190924213638.GE20858@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=antonios.motakis@huawei.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=git@vger.kernel.org \
--cc=groug@kaod.org \
--cc=iank@fsf.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=stefanha@gmail.com \
/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).