git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions

From
CSChristian Schoenebeck <qemu_oss@crudebyte.com>
Date
Sep 23, 2019, 11:19 UTC
Message-ID
<56046367.TiUlWITyhT@silver>
In-Reply-To
<20190909142511.GA20726@sigill.intra.peff.net>
On Montag, 9. September 2019 16:25:12 CEST Jeff King wrote:
Show 46 quoted lines
> On Mon, Sep 09, 2019 at 09:05:45AM -0500, Eric Blake wrote:
> > > But as you can already read from the manual, the overall behaviour of
> > > git
> > > regarding a separate "From:" line in the email body was intended solely
> > > for
> > > the use case sender != author. So in practice (at least in my git
> > > version) git always makes a raw string comparison between sender (name
> > > and email) string and author string and only adds the separate From:
> > > line to the body if they differ.
> > > 
> > > Hence also "git format-patch --from=" only works here if you use a
> > > different author string (name and email) there, otherwise on a perfect
> > > string match it is simply ignored and you end up with only one "From:"
> > > in the email header.> 
> > git folks:
> > 
> > How hard would it be to improve 'git format-patch'/'git send-email' to
> > have an option to ALWAYS output a From: line in the body, even when the
> > sender is the author, for the case of a mailing list that munges the
> > mail headers due to DMARC/DKIM reasons?
> 
> It wouldn't be very hard to ask format-patch to just handle this
> unconditionally. Something like:
> 
> diff --git a/pretty.c b/pretty.c
> index e4ed14effe..9cf79d7874 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -451,7 +451,8 @@ void pp_user_info(struct pretty_print_context *pp,
>  		map_user(pp->mailmap, &mailbuf, &maillen, &namebuf, &namelen);
> 
>  	if (cmit_fmt_is_mail(pp->fmt)) {
> -		if (pp->from_ident && ident_cmp(pp->from_ident, &ident)) {
> +		if (pp->always_use_in_body_from ||
> +		    (pp->from_ident && ident_cmp(pp->from_ident, &ident))) {
>  			struct strbuf buf = STRBUF_INIT;
> 
>  			strbuf_addstr(&buf, "From: ");
> 
> but most of the work would be ferrying that option from the command line
> down to the pretty-print code.
> 
> That would work in conjunction with "--from" to avoid a duplicate. It
> might require send-email learning about the option to avoid doing its
> own in-body-from management. If you only care about send-email, it might
> be easier to just add the option there.

Would it simplify the changes in git if that would be made a "git config [--global]" setting only? That is, would that probably simplify that task to one simple function call there in pretty.c?

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-formatfrom

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?

Best regards, Christian Schoenebeck

Previous: Jeff KingNext: Jeff King
Message 3 of 7 in “Re: [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions”
  1. Eric BlakeSep 9, 2019
  2. Jeff KingSep 9, 2019
  3. Christian SchoenebeckSep 23, 2019
  4. Jeff KingSep 23, 2019
  5. git format.from (was: 9p: Fix file ID collisions)Christian Schoenebeck, Sep 24, 2019
  6. Jeff KingSep 24, 2019
  7. Junio C HamanoSep 9, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.