mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Christian Schoenebeck <>
	Greg Kurz <>,,,, Ian Kelling <>
Subject: Re: git format.from (was: 9p: Fix file ID collisions)
Date: Tue, 24 Sep 2019 17:36:38 -0400	[thread overview]
Message-ID: <> (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):
> For instance the email header:
> From: "Bob Bold" <>
> is automatically replaced by lists by something like
> From: "Bob Bold via Somelist" <>
> 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" <>
> 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.


  reply	other threads:[~2019-09-24 21:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <4642438.ai5u8AxThJ@silver>
     [not found]     ` <1897173.eDCz7oYxVq@silver>
2019-09-09 14:05       ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Eric Blake
2019-09-09 14:25         ` Jeff King
2019-09-23 11:19           ` Christian Schoenebeck
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 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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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

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