From: Jeff King <peff@peff.net> To: Christian Schoenebeck <qemu_oss@crudebyte.com> Cc: qemu-devel@nongnu.org, berrange@redhat.com, stefanha@gmail.com, Greg Kurz <groug@kaod.org>, git@vger.kernel.org, antonios.motakis@huawei.com, dgilbert@redhat.com, Ian Kelling <iank@fsf.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
WARNING: multiple messages have this Message-ID (diff)
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 21:36 UTC|newest] Thread overview: 45+ 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:05 ` Eric Blake 2019-09-09 14:25 ` Jeff King 2019-09-09 14:25 ` Jeff King 2019-09-23 11:19 ` Christian Schoenebeck 2019-09-23 11:19 ` Christian Schoenebeck via 2019-09-23 22:24 ` Jeff King 2019-09-23 22:24 ` Jeff King 2019-09-24 9:03 ` git format.from (was: 9p: Fix file ID collisions) Christian Schoenebeck 2019-09-24 9:03 ` Christian Schoenebeck via 2019-09-24 21:36 ` Jeff King [this message] 2019-09-24 21:36 ` Jeff King 2019-09-09 18:41 ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Junio C Hamano 2019-09-09 18:41 ` 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.