On Wed, Oct 12, 2016 at 01:53:52PM -0700, Junio C Hamano wrote: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > > >>> If it's not in the body of the message, then where is it? > >> > >> This point is clarified in the thread > >> http://marc.info/?l=linux-wireless&m=147625930203434&w=2, which is > >> with my upstream maintainer. > > > > Which explicitly states that the syntax is not [$number], but # $number, > > right? > > But I do not think that works, either. Let's step back. > > People write things like these > > Cc: Stable <stable@xxxxxxxxxxxxxxx> # 4.8 > Cc: Stable <stable@xxxxxxxxxxxxxxx> [4.8+] > > in the trailer part in the body of the message. Are these lines > meant to be usable if they appear as Cc: headers of an outgoing > piece of e-mail as-is? I think the answer is pretty clearly no. It's just that historically we have auto-munged it into something useful. I think the viable options are basically: 1. Tell people not to do that, and to do something RFC compliant like "Stable [4.8+]" <stable@xxxxxxxxxxxxxxx>. This is a little funny for git because we otherwise do not require things like rfc-compliant quoting for our name/email pairs. But it Just Works without anybody having to write extra code, or worry about corner cases in parsing. 2. Drop everything after the trailing ">". This gives a valid rfc2822 cc, and people can pick the "# 4.8" from the cc line in the body. 3. Rewrite A <B@C> D into A D <B@C> regardless of what is in "D". This retains the information in the rfc2822 cc. Starting from scratch, I'd say that (2) seems like a good combination of simplicity and friendliness. But (3) matches what we have done historically (and still do at least for some values of "D", and depending on the presence of Mail::Address). Once we decide on a behavior, it seems like we should be able to apply it consistently with or without Mail::Address by grabbing the bits after the final ">". Larry seems to be against (2), but I'm not sure I understand why pulling the value from the in-body cc (which gets copied into the commit message by git-am, too) would be a problem. -Peff