Junio C Hamano <gits...@pobox.com> writes: > People write things like these > > Cc: Stable <sta...@vger.kernel.org> # 4.8 > Cc: Stable <sta...@vger.kernel.org> [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 this is not the right question. The relevant one is: should these lines be accepted by git and turned into something usable if they appear as Cc: headers of an outgoing piece of e-mail? I.e. "Be liberal in what you accept, and conservative in what you send". If you have Mail::Address installed, this is already possible. With pre-2.6, I did not re-test, but I think it was using the addresses as-is, which probably worked but AFAICT created non-RCF-compliant emails. > "error: unable to extract a valid address from:" is followed by > > Stable <sta...@vger.kernel.org#4.8> > Stable <sta...@vger.kernel.org[4.8+]> > > which is not ideal. I'd actually even say "broken" ;-). If we decide to reject these, we should at least give a sensible error message. > If I were to issue a decree, I would say that people should stop > suggesting to put RFC-bogus things on the Cc: line. As you > mentioned, things like: > > Cc: Stable (4.8+) <sta...@vger.kernel.org> > Cc: "Stable 4.8+" <sta...@vger.kernel.org> > > are perfectly readable alternative that are still RFC-kosher. I do support those, but if there's an established tradition of using # ... trailer, then I don't think we should be the ones forcing it to stop. > Things may have appeared to work by accident, and things may still > work by accident, depending on the vintage and availability of > Mail::Address package (which seems to be the case), but it is not > worth risking random breakages that depends on what other people > use in the first place, no? The "depending on the availability of Mail::Address" is what bothers me most. Suppose we make a strong statement here that this # 4.8 should stop. Then some users will listen to that statements, but others won't read the thread, test with their own git that it works, and recommend it to users for whom it doesn't. > That is, even though people seem to expect "send-email --cc" to > somehow be able to judge that " # 4.8" and " [4.8+]" are cruft not > meant as part of a valid address, I do not think it is a realistic > expectation. How would it know "Cc: Stable <a...@re.ss> 4.8, 4.9" > has garbage " 4.8, 4.9" that needs to be stripped, while "Cc: Stable > <a...@re.ss> 4.8, torva...@linux-foundation.org" has two valid > addresses that need to be CC'ed and " 4.8" is the only thing that is > unwanted? We clearly can't guess, but we can be consistent with Mail::Address, so that git's behavior depends less on its availability. Patch follows doing that. -- Matthieu Moy http://www-verimag.imag.fr/~moy/
