qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Schoenebeck via <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: berrange@redhat.com, stefanha@gmail.com,
	Christian Schoenebeck <qemu_oss@crudebyte.com>,
	Greg Kurz <groug@kaod.org>,
	dgilbert@redhat.com, Jeff King <peff@peff.net>,
	Ian Kelling <iank@fsf.org>,
	antonios.motakis@huawei.com, git@vger.kernel.org
Subject: git format.from (was: 9p: Fix file ID collisions)
Date: Tue, 24 Sep 2019 11:03:38 +0200	[thread overview]
Message-ID: <3312839.Zbq2WQg2AT@silver> (raw)
In-Reply-To: <20190923222415.GA22495@sigill.intra.peff.net>

On Dienstag, 24. September 2019 00:24:15 CEST Jeff King wrote:
> > On the other hand, considering the already existing --from argument and
> > "format.from" config option:
> > https://git-scm.com/docs/git-config#Documentation/git-config.txt-formatfro
> > m
> > 
> > Wouldn't it make sense to just drop the currently existing sender !=
> > author
> > string comparison in git and simply always add the "From:" line to the
> > email's body if "format.from yes" is used, instead of introducing a
> > suggested 2nd (e.g. "always-from") option? I mean sure automatically
> > removing redundant information in the generated emails if sender ==
> > author sounds nice on first thought, but does it address anything useful
> > in practice to justify introduction of a 2nd related option?
> 
> 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.

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. :-)

Best regards,
Christian Schoenebeck




  reply	other threads:[~2019-09-24  9:05 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                         ` Christian Schoenebeck via [this message]
2019-09-24 21:36                           ` git format.from (was: 9p: Fix file ID collisions) Jeff King
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=3312839.Zbq2WQg2AT@silver \
    --to=qemu-devel@nongnu.org \
    --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=peff@peff.net \
    --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).