A minor thing.
Commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 is displayed thusly:
commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 Author: Zhang, Rui <rui.zhang@intel.com> Date: Thu Apr 10 16:20:23 2008 +0800
ACPI: update thermal temperature
but that isn't a valid email address. Because it contains a comma it must be quoted: "Zhang, Rui".
I assume that something in the git toolchain removed his quotes, and that was arguably incorrect.
Linus TorvaldsRe: email address handling
On Thu, 31 Jul 2008, Andrew Morton wrote:
> > A minor thing. > > Commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 is displayed thusly: > > commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 > Author: Zhang, Rui <rui.zhang@intel.com> > Date: Thu Apr 10 16:20:23 2008 +0800 > > ACPI: update thermal temperature > > but that isn't a valid email address. Because it contains a comma it > must be quoted: "Zhang, Rui".
The email address is rui.zhang@intel.com.
The name is Zhang, Rui.
Git at no point ever mixes the two up. It's _not_ one field ("Zhang, Rui <rui.zhang@intel.com>"), it's literally two different parts that you set separately, that just get shown (and encoded in the commit, for that matter) in a way that resembles a single email address.
> I assume that something in the git toolchain removed his quotes, and > that was arguably incorrect.
No, it would be incorrect to keep them, because the name doesn't contain the quotes. The name is just that
Zhang, Rui
part.
I've considered having the email->name detection change "A, B" into "B A", but it's not always right, so it doesn't try to munge the names it finds in other ways except to remove obvious crud from the ends.
And Andrew, this is true of Signed-off-by: lines too, btw. If you actually want to send emails to them, _then_ you need to add quotes to follow the email rules.
Linus
Re: email address handling
On Fri, 1 Aug 2008 12:34:58 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually > want to send emails to them, _then_ you need to add quotes to follow the > email rules.
That's how I noticed it - copied, pasted, MTA barfed.
Converting a usable name+email-address into an unusable one seems ... unuseful.
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > That's how I noticed it - copied, pasted, MTA barfed. > > Converting a usable name+email-address into an unusable one seems ... unuseful.
Umm. Those signed-off ones weren't even _converted_ They were written by people.
Also, you seemed to miss the point that it's not a name+email-address.
It's a name. Oh, and there's an email address too. But they aren't connected. We often just print out the name *without* the email address. Why should those things have to know about some totally irrelevant email quoting rules? They weren't emails, didn't know about it, and didn't care.
Linus
Junio C HamanoRe: email address handling
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 1 Aug 2008, Andrew Morton wrote: >> >> That's how I noticed it - copied, pasted, MTA barfed. >> >> Converting a usable name+email-address into an unusable one seems ... unuseful. > > Umm. Those signed-off ones weren't even _converted_ They were written by > people. > > Also, you seemed to miss the point that it's not a name+email-address. > > It's a name. Oh, and there's an email address too. But they aren't > connected. We often just print out the name *without* the email address. > Why should those things have to know about some totally irrelevant email > quoting rules? They weren't emails, didn't know about it, and didn't care.
One place that can matter is git-send-email.perl; IIRC, it reads from the S-o-b:, Cc: and From: lines people write, and these follow "name next to address, that does not care irrelevant email quoting rules" format. I do not think send-email currently does much about quoting them, but I think it should be the right place to do so.
Re: email address handling
On Fri, 1 Aug 2008 12:56:44 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Fri, 1 Aug 2008, Andrew Morton wrote: > > > > That's how I noticed it - copied, pasted, MTA barfed. > > > > Converting a usable name+email-address into an unusable one seems ... unuseful. > > Umm. Those signed-off ones weren't even _converted_ They were written by > people.
This was the Author: line.
Afaik that person doesn't send patches via git, and that this text by some means was transferred into git from an emailed patch.
So unless he explicitly typed a "From:" line (without quoting his name) into the top of his changelog, some piece of software somewhere has stripped the quotes when it was converting his name from the email headers into the git Author: line.
> Also, you seemed to miss the point that it's not a name+email-address.
I know exactly what it is.
> It's a name. Oh, and there's an email address too. But they aren't > connected. We often just print out the name *without* the email address. > Why should those things have to know about some totally irrelevant email > quoting rules? They weren't emails, didn't know about it, and didn't care.
Well, as I said, it's a minor point. It's just that converting something which _can_ be copied and pasted into an MUA into something which cannot seems... odd.
Most sane MUA's will omit the quotes if the name part does not need them, so simply retaining the quotes if they were originally there would be an OK thing to do.
So how serious is this issue?
Well, if all MUAs either generate synchronous error messages or will insert the quotes for you then not very serious at all.
If, however, there are MUA+MTA combinations which do _not_ inform about or correct the error then this failure to quote the name could cause people's emails to get lost altogether, which is a bit serious.
Also, _most_ git Author: lines _can_ be successfully copied-and-pasted into an MUA. The fact that a small minority of git Author: lines cannot be used this way is a bit dangerous.
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > This was the Author: line.
So?
I mean, it's not sending email, is it? It says "Author:".
You could have just inserted the actual email address. Or something.
Linus
Re: email address handling
On Fri, 1 Aug 2008 13:17:11 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Fri, 1 Aug 2008, Andrew Morton wrote: > > > > This was the Author: line. > > So?
So all the other things I said.
> I mean, it's not sending email, is it? It says "Author:". > > You could have just inserted the actual email address. Or something. >
pls read earlier email.
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > pls read earlier email.
I did. It seems that your complaint is:
> So unless he explicitly typed a "From:" line (without quoting his name) > into the top of his changelog, some piece of software somewhere has > stripped the quotes when it was converting his name from the email > headers into the git Author: line.
And yes, git will strip out all the crap and try to make it into a real name.
The part _you_ don't seem to understand is that my point is
- git changed that "From:" line to an "Author:" line
- "git log" isn't an email system. It's a human-readable (and machine-parseable, for that matter) log.
If you want to turn it into emails, you need to follow the email rules. You're cutting-and-pasting anyway, it's not like this is fundamentally hard.
Linus
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Linus Torvalds wrote:
> > If you want to turn it into emails, you need to follow the email rules. > You're cutting-and-pasting anyway, it's not like this is fundamentally > hard.
Btw, if sending emails was the _only_ thing that Author line was used for, or even the main thing, then it would make sense to keep it in some email format. But it really isn't. Sending emails to people is the _least_ common thing you do with it. Most of the time you just want to see the name in a nice readable format.
Linus
Re: email address handling
On Fri, 1 Aug 2008 13:40:00 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Fri, 1 Aug 2008, Andrew Morton wrote: > > > > pls read earlier email. > > I did. It seems that your complaint is: > > > So unless he explicitly typed a "From:" line (without quoting his name) > > into the top of his changelog, some piece of software somewhere has > > stripped the quotes when it was converting his name from the email > > headers into the git Author: line. > > And yes, git will strip out all the crap and try to make it into a real > name. > > The part _you_ don't seem to understand is that my point is > > - git changed that "From:" line to an "Author:" line > > - "git log" isn't an email system. It's a human-readable (and > machine-parseable, for that matter) log.
What you're describing here is some explicit or implicit git design decision and then telling me how it's implemented.
Well, what I'm saying is that it was an incorrect design decision.
> If you want to turn it into emails, you need to follow the email rules. > You're cutting-and-pasting anyway, it's not like this is fundamentally > hard.
Here is a real story from a real user of your software:
I very very frequently copy and paste name+email address out of git output and into an MUA. Have done it thousands and thousands of times, and it has always worked. I'm sure that many others do the same thing.
Yesterday, I copied and pasted what _looked_ like a usable name+email-address from some git output and into an MUA. Unlike the thousands of preceding times, it did not work.
I think it was reasonable of me to assume that it would work. Blaming the surprised and misled user for not understanding some earlier internal design decision didn't satisfy him!
True story! From a user.
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > Well, what I'm saying is that it was an incorrect design decision.
And I'm saying that I disagree.
> Yesterday, I copied and pasted what _looked_ like a usable > name+email-address from some git output and into an MUA. Unlike the > thousands of preceding times, it did not work. > > I think it was reasonable of me to assume that it would work. Blaming > the surprised and misled user for not understanding some earlier > internal design decision didn't satisfy him! > > True story! From a user.
Hey, there are tons of surprises in life. Users make mistakes and assumptions that turn out to not be true. If you think you can avoid all such issues, I think you aren't living in the real world.
You'll be shocked to hear that even the so-called _email_ address isn't necessarily valid at all at times. Look closer, and you'll find email addresses that don't work at all. It turns out that if you don't set it explicitly, git will guess, and sometimes the end result won't actually work as an email address.
Beign surprised and then saying "I was surprised, so the whole design is broken" - that's a very silly standpoint to make. I suggest you reconsider. How many times have you had people "surprised" by correct kernel behaviour? Happens all the time.
Do you think they are all indicative of bad design, or maybe just "welcome to the real world - your preconceived notions didn't turn out to be accurate after all"?
It's a design decision to show the name as readably as possible. One that I think was correct.
Linus
Johannes SchindelinRe: email address handling
Hi,
On Fri, 1 Aug 2008, Andrew Morton wrote:
> I very very frequently copy and paste name+email address out of git > output and into an MUA. Have done it thousands and thousands of times, > and it has always worked. I'm sure that many others do the same thing.
$ git log --pretty=email
after this patch:
-- snipsnap --
pretty.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c index 33ef34a..ba50b54 100644 --- a/pretty.c +++ b/pretty.c @@ -140,14 +140,20 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb, if (fmt == CMIT_FMT_EMAIL) { char *name_tail = strchr(line, '<'); int display_name_length; + int need_quotes; if (!name_tail) return; while (line < name_tail && isspace(name_tail[-1])) name_tail--; display_name_length = name_tail - line; + need_quotes = !!memchr(line, ',', display_name_length); filler = ""; strbuf_addstr(sb, "From: "); + if (need_quotes) + strbuf_addch(sb, '"'); add_rfc2047(sb, line, display_name_length, encoding); + if (need_quotes) + strbuf_addch(sb, '"'); strbuf_add(sb, name_tail, namelen - display_name_length); strbuf_addch(sb, '\n'); } else {
Junio C HamanoRe: email address handling
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 1 Aug 2008, Andrew Morton wrote: > >> I very very frequently copy and paste name+email address out of git >> output and into an MUA. Have done it thousands and thousands of times, >> and it has always worked. I'm sure that many others do the same thing.
> > $ git log --pretty=email > > after this patch:
You are quoting only Author: and not Signed-off-by: and Cc: that are used for e-mail purposes. I already said send-email is the right place to do this kind of thing, didn't I? Your patch makes things worse by making some <name, mail> pair already quoted and some others don't.
Please don't do this.
Johannes SchindelinRe: email address handling
Hi,
On Fri, 1 Aug 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > On Fri, 1 Aug 2008, Andrew Morton wrote: > > > >> I very very frequently copy and paste name+email address out of git > >> output and into an MUA. Have done it thousands and thousands of times, > >> and it has always worked. I'm sure that many others do the same thing. > > > > > $ git log --pretty=email > > > > after this patch: > > You are quoting only Author: and not Signed-off-by: and Cc: that are used > for e-mail purposes.
You might have realized that this was not a proper patch with a commit message and a SOB?
As for Cc: I agree. But not for S-O-B: this is not an email header. And I was very specific in only changing the behavior for "pretty=email".
At least _I_ was surprised that pretty=email did not behave as if it was outputting email headers.
I agree with Linus for pretty=non-email, but not at all for pretty=email.
> I already said send-email is the right place to do this kind of thing, > didn't I?
For the given scenario send-email is completely irrelevant.
Ciao, Dscho
Junio C HamanoRe: email address handling
Andrew Morton <akpm@linux-foundation.org> writes:
>> The part _you_ don't seem to understand is that my point is >> >> - git changed that "From:" line to an "Author:" line >> >> - "git log" isn't an email system. It's a human-readable (and >> machine-parseable, for that matter) log. > > What you're describing here is some explicit or implicit git design > decision and then telling me how it's implemented. > > Well, what I'm saying is that it was an incorrect design decision.
What is the objective of your statement in this discussion? Further add fuel to flame, or to seek avenues that lead to some improvement in a constructive way?
The thing is, I do not think reverting that design decision is an option at this point. People's repositories record <Name, Email> pair already in "human readable" form, and people's scripts are assuming that.
I misspoke about git-send-email earlier; it already has sanitize_address() that massages the addresses on From: To: and Cc: lines. In fact, it even seems to have logic to avoid double-quoting, so it would be Ok if you changed the design decision this late in the game for that particular script, but that does not mean it is a good change --- other scripts people may have built around git would need to change.
So the earlier patch from Dscho (Johannes) may be a step in the right direction, but if we are going to rewrite the author information, (1) it has to be an option, and (2) when rewriting, it should not be just From:; but Signed-off-by:, Cc: and other <Name, Email> pairs at the end of the log message would need similar treatment, so that you can cut and paste any of them to your MUA.
Re: email address handling
On Fri, 01 Aug 2008 14:50:05 -0700 Junio C Hamano <gitster@pobox.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes: > > >> The part _you_ don't seem to understand is that my point is > >> > >> - git changed that "From:" line to an "Author:" line > >> > >> - "git log" isn't an email system. It's a human-readable (and > >> machine-parseable, for that matter) log. > > > > What you're describing here is some explicit or implicit git design > > decision and then telling me how it's implemented. > > > > Well, what I'm saying is that it was an incorrect design decision. > > What is the objective of your statement in this discussion? Further add > fuel to flame, or to seek avenues that lead to some improvement in a > constructive way?
Well initially it was to work out why the heck my git-log output had stripped the quotes from that person's name, making it unusable for email purposes. I'd actually assumed that it was a bug.
> The thing is, I do not think reverting that design decision is an option > at this point. People's repositories record <Name, Email> pair already in > "human readable" form, and people's scripts are assuming that. > > I misspoke about git-send-email earlier; it already has sanitize_address() > that massages the addresses on From: To: and Cc: lines. In fact, it even > seems to have logic to avoid double-quoting, so it would be Ok if you > changed the design decision this late in the game for that particular > script, but that does not mean it is a good change --- other scripts > people may have built around git would need to change. > > So the earlier patch from Dscho (Johannes) may be a step in the right > direction, but if we are going to rewrite the author information, (1) it > has to be an option, and (2) when rewriting, it should not be just From:; > but Signed-off-by:, Cc: and other <Name, Email> pairs at the end of the > log message would need similar treatment, so that you can cut and paste > any of them to your MUA.
I preserve the quotes (when present) in signoffs for this exact reason.
Theodore TsoRe: email address handling
On Fri, Aug 01, 2008 at 02:58:04PM -0700, Andrew Morton wrote:
> > I preserve the quotes (when present) in signoffs for this exact reason. >
Heh. I include quotes in my Signed-off-by:
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Because I assumed the format of the DCO was an RFC-822 compliant header format. It otherwise *looks* like an RFC-822 format, so I assumed it should follow all of the rules, including the ones about quoting.
How about this as a compromise? Git continues to store the names in its internal format as it always does, but there is a configuration option which controls whether the various Author: and Committer: fields when displayd by git-log are in RFC-822 format or not.
- Ted
Re: email address handling
On Fri, 1 Aug 2008 18:15:39 -0400 Theodore Tso <tytso@mit.edu> wrote:
> How about this as a compromise? Git continues to store the names in > its internal format as it always does, but there is a configuration > option which controls whether the various Author: and Committer: > fields when displayd by git-log are in RFC-822 format or not.
Well I believe/expect/hope that git's name+email-address transformation goes via a lookup in the kernel's .mailmap file.
And the existing .mailmap appears to have taken care that all the "name" parts are in an MUA-usable form. There are no periods or commas.
So if everyone had a .mailmap entry then
- The Author: lines would all be MUA usable
- The Author lines would all be in their owners' preferred form. I mean, converting
"Morton, Andrew"
into
Morton, Andrew
didn't improve things much.
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > And the existing .mailmap appears to have taken care that all the > "name" parts are in an MUA-usable form. There are no periods or > commas.
Umm. Or quotes? I don't think so. Or even periods? You must not have looked at things, I found one at the very first screenful.
Ed L. Cashin <ecashin@coraid.com> Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> S.Çağlar Onur <caglar@pardus.org.tr>
adn that's just basically ignoring the fact that we only add mailmap entries for people who can't get it right other ways (where admittedly sometimes the "can't get it right" comes from the people in between: poor Çağlar has had his name corrupted so many times that it's funny).
Linus
Re: email address handling
On Fri, 1 Aug 2008 15:34:16 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Fri, 1 Aug 2008, Andrew Morton wrote: > > > > And the existing .mailmap appears to have taken care that all the > > "name" parts are in an MUA-usable form. There are no periods or > > commas. > > Umm. Or quotes? I don't think so. Or even periods? You must not have > looked at things, I found one at the very first screenful. > > Ed L. Cashin <ecashin@coraid.com> > Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> > S.__a__lar Onur <caglar@pardus.org.tr>
oh. So .mailmap isn't usable either. Argh.
I guess it'd be fairly simple to slap quotes around anything which contains fishy characters.
> adn that's just basically ignoring the fact that we only add mailmap > entries for people who can't get it right other ways (where admittedly > sometimes the "can't get it right" comes from the people in between: poor > __a__lar has had his name corrupted so many times that it's funny).
^^^^^^^^ (lol)
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > S.__a__lar Onur <caglar@pardus.org.tr> > > oh. So .mailmap isn't usable either. Argh.
Btw, your mailer really is broken. It seems to have turned my correct utf-8 email into US-ASCII.
Or at least it was correct when it came back to me. I don't see the corruption. But your mailer seems to be unable to handle any complex character sets and did
X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII
and I wonder why?
Yeah, I feel superior, because alpine actually gets things right these days. I too used to be character-set-confused.
Linus
Re: email address handling
On Fri, 1 Aug 2008 15:52:36 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Fri, 1 Aug 2008, Andrew Morton wrote: > > > S.__a__lar Onur <caglar@pardus.org.tr> > > > > oh. So .mailmap isn't usable either. Argh. > > Btw, your mailer really is broken. It seems to have turned my correct > utf-8 email into US-ASCII. > > Or at least it was correct when it came back to me. I don't see the > corruption. But your mailer seems to be unable to handle any complex > character sets and did > > X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > > and I wonder why? > > Yeah, I feel superior, because alpine actually gets things right these > days. I too used to be character-set-confused. >
sylpheed. If you use its internal editor it mostly gets things right. But if you use its use-external-editor feature it messes up those things when saving out to its temporary file. And it was written by a Japanese guy.
I'll often fix it in changelogs by re-editing the changelog and doing a copy-n-paste from sylpheed's display window into the editor, which does work. All a bit of a pain though.
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Linus Torvalds wrote:
> > S.Çağlar Onur <caglar@pardus.org.tr>
Btw, poor guy is _really_ screwed. He'd show up as
"=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur" <caglar@pardus.org.tr>
which must really hurt.
Can you not see how STUPID it would be to say that the name should be shown as an email encoding requires it?
Really. Just admit that you were wrong. The fact is, asking for rfc2822 encoding in logs etc is a HORRIBLY HORRIBLY stupid thing to do.
What you really want was just something you could cut-and-paste into your mailer. Which actually means that the only special character is probably ",", and your claims of how bad the design was that it didn't leave the total mess that rfc2822 is was actually not true, and was based on simply not knowing how nasty the real world is...
Quote frankly, If I had one of the Finnish special characters in my name, I'd piss on your grave if you suggested that. Try to guess what something like
=?ISO-8859-15?Q?Linus_T=F6rnqvist?= <torvalds@linux-foundation.org>
is supposed to be.
Linus
Karl HasselströmRe: email address handling
On 2008-08-01 15:49:43 -0700, Linus Torvalds wrote:
> Try to guess what something like > > =?ISO-8859-15?Q?Linus_T=F6rnqvist?= <torvalds@linux-foundation.org> > > is supposed to be.
Very readable to me. Because every so often some piece of software reminds me that the ö in my name is 0xf6 in latin1/9 ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalleLinus TorvaldsRe: email address handling
Btw, the real issue here is
- why do you want to make things uglier and make up stupid rules that are irrelevant to git, just for something that you admit you hadn't ever even _noticed_ until now, and now that you know about it it's not even a problem any more?
especially as
- we know people won't do the quoting _anyway_, since we actually have tons of examples of that in the kernel as-is.
Quoting should be for _tools_, not for people. And even if we did it, we probably wouldn't be fully rfc2822-compliant anyway, because anybody sane would decide to not quote '@' and '.', rigth?
Because those don't actually really have special meaning (yeah, they are "special" characters in rfc-2822, but nobody cares, and the MUA can do it for us, no)?
So now we'd actually not really be rfc-compliant _anyway_, because everybody really realizes just how annoying that would really be.
Linus
Re: email address handling
On Fri, 1 Aug 2008 15:39:37 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > Btw, the real issue here is > > - why do you want to make things uglier and make up stupid rules that are > irrelevant to git, just for something that you admit you hadn't ever > even _noticed_ until now, and now that you know about it it's not even > a problem any more?
None of that is correct.
The real issue here is:
- Why do you want to take usable RFC-compliant email addresses and mangle them in a manner which still doesn't match the person's actual name and which makes unsuspecting users of git potentially lose important email communications?
Ain't framing great?
> especially as > > - we know people won't do the quoting _anyway_, since we actually have > tons of examples of that in the kernel as-is. > > Quoting should be for _tools_, not for people. And even if we did it, we > probably wouldn't be fully rfc2822-compliant anyway, because anybody sane > would decide to not quote '@' and '.', rigth? > > Because those don't actually really have special meaning (yeah, they are > "special" characters in rfc-2822, but nobody cares, and the MUA can do it > for us, no)? > > So now we'd actually not really be rfc-compliant _anyway_, because > everybody really realizes just how annoying that would really be. >
Linus, just admit it: copying and pasting from git-log output into the MUA is *useful*. And you've made it less reliable.
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > Linus, just admit it: copying and pasting from git-log output into the MUA > is *useful*. And you've made it less reliable.
Oh, I admit it is useful.
But your "solution" is actually MUCH MUCH MUCH worse than what git does.
That's my argument here. Life is tough. Not everthing is going to be easy. Your solution would "work", but it would be a horrid piece of crap.
Linus
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Linus Torvalds wrote:
> > That's my argument here. Life is tough. Not everthing is going to be > easy. Your solution would "work", but it would be a horrid piece of crap.
..and I really think that the
"=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur" <caglar@pardus.org.tr>
example should be the one that makes you say "Ok, you're right".
The undeniable fact is, if we kept things in that format, even your broken mailer wouldn't have corrupted it. You could cut-and-paste things, and they's show up correctly at the other end, regardless of whether the problem is with your mailer or with the cut-and-paste, or anything else.
So clearly, "=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur" _must_ be the superior format that git should have used, no?
Because clearly that is the most automation-friendly thing that _never_ requires anybody to think at all, and you can cut-and-paste it between programs without ever having to worry about anything at all. No special characters, no special meanings, no need to worry about limitations of implementation.
So the fact that git completely FUCKS IT UP, and when you do 'git log' git will have corrupted this to
Author: S.Çağlar Onur <caglar@pardus.org.tr>
is clearly git doing the wrong thing. Right?
WRONG.
The fact is, git does the right thing. And yes, it means that you cannot just blindly cut-and-paste. And yes, it means that your mailer actually has to work right for you to even -see- the right email address. And yes, it means that any number of things can screw up, and corrupt it.
But it is STILL the right thing. Because what matters more than your ability to cut-and-paste or anything like that is the fact that we should make things look sane.
The thing is, you can actually get git to output the crazy names. Just do
git show --pretty=email 37a4c940749670671adab211a2d9c9fed9f3f757
and now you get the email-prettified thing for at least the author. No, git won't corrupt the actual message, so the Signed-off-by: lines will still show Çağlar's first name, but you can actually get back that odd format.
(In fact, --pretty=email will do it as
From: =?utf-8?q?S.=C3=87a=C4=9Flar=20Onur?= <caglar@pardus.org.tr>
which is admittedy _even_uglier_, but whatever.. The difference between really f*cking ugly and really f*cking uglier is not really relevant).
Linus
Johannes SchindelinRe: email address handling
Hi,
On Fri, 1 Aug 2008, Linus Torvalds wrote:
> The thing is, you can actually get git to output the crazy names. Just > do > > git show --pretty=email 37a4c940749670671adab211a2d9c9fed9f3f757 > > and now you get the email-prettified thing for at least the author.
Ah, there lies the rub (you forgot that the original complaint was about a comma, and pretty=email does not handle those):
-- snipsnap --
pretty.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/pretty.c b/pretty.c index 33ef34a..9db0333 100644 --- a/pretty.c +++ b/pretty.c @@ -79,7 +79,8 @@ int non_ascii(int ch) static int is_rfc2047_special(char ch) { - return (non_ascii(ch) || (ch == '=') || (ch == '?') || (ch == '_')); + return (non_ascii(ch) || (ch == '=') || (ch == '?') || (ch == '_') || + (ch == ',') || (ch == '"') || (ch == '\'')); } static void add_rfc2047(struct strbuf *sb, const char *line, int len, @@ -89,7 +90,7 @@ static void add_rfc2047(struct strbuf *sb, const char *line, int len, for (i = 0; i < len; i++) { int ch = line[i]; - if (non_ascii(ch)) + if (is_rfc2047_special(ch)) goto needquote; if ((i + 1 < len) && (ch == '=' && line[i+1] == '?')) goto needquote;
Linus TorvaldsRe: email address handling
On Sat, 2 Aug 2008, Johannes Schindelin wrote:
> > Ah, there lies the rub (you forgot that the original complaint was about > a comma, and pretty=email does not handle those):
Indeed.
I wonder where that is_rfc2047_special() function came from. The list of "special" characters is totally bogus.
The real RFC has comma, but it has a lot of other characters too:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" /
"<" / "> / "/" / "[" / "]" / "?" / "." / "="because basically the rfc2047 encoding has to be a superset of the 822 (and later 2822) encodings.
Linus
Junio C HamanoRe: email address handling
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 2 Aug 2008, Johannes Schindelin wrote: >> >> Ah, there lies the rub (you forgot that the original complaint was about >> a comma, and pretty=email does not handle those): > > Indeed. > > I wonder where that is_rfc2047_special() function came from.
It came from the earlier patch from Dscho I rejected yesterday ;-)
Johannes SchindelinRe: email address handling
Hi,
On Sat, 2 Aug 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes: > > > I wonder where that is_rfc2047_special() function came from.
It comes straight from cdd406e(CMIT_FMT_EMAIL: Q-encode Subject: and display-name part of From: fields.).
Ciao, Dscho
Linus TorvaldsRe: email address handling
On Sat, 2 Aug 2008, Johannes Schindelin wrote:
> Hi, > > On Sat, 2 Aug 2008, Junio C Hamano wrote: > > > Linus Torvalds <torvalds@linux-foundation.org> writes: > > > > > I wonder where that is_rfc2047_special() function came from. > > It comes straight from cdd406e(CMIT_FMT_EMAIL: Q-encode Subject: and > display-name part of From: fields.).
That's not what I meant.
I meant "what drugs induced somebody to write that function and give it that name, since it clearly has never seen rfc2047, and has nothing to do with it".
In other words, it sure as hell didn't come from the rfc2047 in this universe, so it must have come from some exciting alternate alien universe with different laws of nature and internet.
Or maybe there's just another rfc2047 that I've not heard of.
Linus
Junio C HamanoRe: email address handling
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 2 Aug 2008, Johannes Schindelin wrote: >> >> Ah, there lies the rub (you forgot that the original complaint was about >> a comma, and pretty=email does not handle those): > > Indeed. > > I wonder where that is_rfc2047_special() function came from. The list of > "special" characters is totally bogus.
This function is about quoting inside dq pair, so the function does not look at the set you listed. It is about quoting non-ascii chars using the ?charset?Q? or ?charset?B? notation.
If we want to use double quotes that should be done elsewhere, not in that function.
Junio C HamanoRe: email address handling
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes: > >> On Sat, 2 Aug 2008, Johannes Schindelin wrote: >>> >>> Ah, there lies the rub (you forgot that the original complaint was about >>> a comma, and pretty=email does not handle those): >> >> Indeed. >> >> I wonder where that is_rfc2047_special() function came from. The list of >> "special" characters is totally bogus. > > This function is about quoting inside dq pair, so the function does not
s/is about/is NOT about/;
Sorry, I should grab coffee before continuing.
> look at the set you listed. It is about quoting non-ascii chars using the > ?charset?Q? or ?charset?B? notation. > > If we want to use double quotes that should be done elsewhere, not in that > function.
Junio C HamanoRe: email address handling
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>>
>> Ah, there lies the rub (you forgot that the original complaint was about
>> a comma, and pretty=email does not handle those):
>
> Indeed.
>
> I wonder where that is_rfc2047_special() function came from. The list of
> "special" characters is totally bogus.
>
> The real RFC has comma, but it has a lot of other characters too:
>
> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" /
> "<" / "> / "/" / "[" / "]" / "?" / "." / "="
>
> because basically the rfc2047 encoding has to be a superset of the 822
> (and later 2822) encodings.Hmm, you're right. This has to be trickier than I originally thought it would be ... ;-)
Linus TorvaldsRe: email address handling
On Fri, 1 Aug 2008, Andrew Morton wrote:
> > I preserve the quotes (when present) in signoffs for this exact reason.
You must be one of the few ones. According to the RFC's, you should quote pretty much any punctuation mark, including "." itself. Which means that things like
Signed-off-by: David S. Miller <davem@davemloft.net>
should be quoted if they were email addresses.
That would be very irritating.
It's even _more_ irritating for things like D'Souza (or Giuseppe D'Eliseo to take a real example from the kernel). For David, we could just not use the "S." - for others, the special characters are very much part of the name. It would also be very irritating for important messages like
Signed-off-by: Linus "I'm a moron" Torvalds <torvalds@osdl.org>
etc, where it sure as heck isn't a rfc2822-compliant email address.
So the thing is, "strict email format" is just very annoying. Git does know how to do (well, it _should_) it for "git send-email", but making the human-readable output ugly just because somebody might want to cut-and-paste it sounds really sad.
You could cut-and-paste just the stuff inside the angle branckets, though. That should work.
Linus
Re: email address handling
On Fri, 1 Aug 2008 15:23:23 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Fri, 1 Aug 2008, Andrew Morton wrote: > > > > I preserve the quotes (when present) in signoffs for this exact reason. > > You must be one of the few ones.
Not the only one. See d67d1c7bf948341fd8678c8e337ec27f4b46b206, 3bf2e77453a87c22eb57ed4926760ac131c84459, ...
> According to the RFC's, you should quote > pretty much any punctuation mark, including "." itself. Which means that > things like > > Signed-off-by: David S. Miller <davem@davemloft.net> > > should be quoted if they were email addresses. > > That would be very irritating.
Yeah, it's ugly as sin. But it has usability benefits. Few people actually need this treatment.
> It's even _more_ irritating for things like D'Souza (or Giuseppe D'Eliseo > to take a real example from the kernel). For David, we could just not use > the "S." - for others, the special characters are very much part of the > name. It would also be very irritating for important messages like > > Signed-off-by: Linus "I'm a moron" Torvalds <torvalds@osdl.org> > > etc, where it sure as heck isn't a rfc2822-compliant email address.
It might be. Look at this guy:
From: Josef "Jeff" Sipek <jsipek@cs.sunysb.edu>
Who later did an edit and became
From: "Josef 'Jeff' Sipek" <jsipek@cs.sunysb.edu>
> So the thing is, "strict email format" is just very annoying. Git does > know how to do (well, it _should_) it for "git send-email", but making the > human-readable output ugly just because somebody might want to > cut-and-paste it sounds really sad.
It didn't make human-readable output ugly. It was already ugly and it just left it alone so it was still usable.
> You could cut-and-paste just the stuff inside the angle branckets, though. > That should work.
Sure. I like to include people's names though.
Perhaps a suitable solution to all this would be to teach more things to use .mailmap transformations and to update that file more.
otoh, if people really want to present themselves to the world in a name-reversed, comma-stuffed, quote-wrapped form then that was their choice..
Junio C HamanoRe: email address handling
Andrew Morton <akpm@linux-foundation.org> writes:
> On Fri, 1 Aug 2008 12:34:58 -0700 (PDT) > Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually >> want to send emails to them, _then_ you need to add quotes to follow the >> email rules. > > That's how I noticed it - copied, pasted, MTA barfed. > > Converting a usable name+email-address into an unusable one seems ... unuseful.
Name is used not just for pasting into your MUA. For example, if your shortlog output showed this, it would be "funny looking":
"Zhang, Rui" (4):
... Andrew Morton (20):
...
...Re: email address handling
On Fri, 01 Aug 2008 13:00:16 -0700 Junio C Hamano <gitster@pobox.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes: > > > On Fri, 1 Aug 2008 12:34:58 -0700 (PDT) > > Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > >> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually > >> want to send emails to them, _then_ you need to add quotes to follow the > >> email rules. > > > > That's how I noticed it - copied, pasted, MTA barfed. > > > > Converting a usable name+email-address into an unusable one seems ... unuseful. > > Name is used not just for pasting into your MUA. For example, if your > shortlog output showed this, it would be "funny looking": > > "Zhang, Rui" (4): > ... > > Andrew Morton (20): > ... > ...
yep. That'd be a git-shortlog bug :)
I really don't care about this much!