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

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

--

On Fri, 1 Aug 2008 12:34:58 -0700 (PDT)
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):

            ...

            ...

--

On Fri, 01 Aug 2008 13:00:16 -0700
yep.  That'd be a git-shortlog bug :)
I really don't care about this much!

--

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

--

On Fri, 1 Aug 2008 12:56:44 -0700 (PDT)
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
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.
--

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

--

On Fri, 1 Aug 2008 13:17:11 -0700 (PDT)
pls read earlier email.

--

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

--

On Fri, 1 Aug 2008 13:40:00 -0700 (PDT)
What you're describing here is some explicit or implicit git design

decision and then telling me how it's implemented.
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.

--

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

On Fri, 01 Aug 2008 14:50:05 -0700
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
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

--

Not the only one.  See d67d1c7bf948341fd8678c8e337ec27f4b46b206,
Yeah, it's ugly as sin.  But it has usability benefits.  Few people
It might be.  Look at this guy:
From: Josef "Jeff" Sipek <jsipek@cs.sunysb.edu>
Who later did an edit and became
It didn't make human-readable output ugly.  It was already ugly and it
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..
--

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

--

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

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

--

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

--

..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...
[ message continues ]

Hi,
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;

--

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

--

Hmm, you're right.  This has to be trickier than I originally thought it

would be ... ;-)
--

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

s/is about/is NOT about/;
--

It came from the earlier patch from Dscho I rejected yesterday ;-)

--

Hi,
It comes straight from cdd406e(CMIT_FMT_EMAIL: Q-encode Subject: and

display-name part of From: fields.).
Ciao,

Dscho
--

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

--

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

--

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

--

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/kalle

--

oh.  So .mailmap isn't usable either.  Argh.
I guess it'd be fairly simple to slap quotes around anything which

  ^^^^^^^^ (lol)
--

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

--

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

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

--

Hi,
$ 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 {

--

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

Hi,
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.
For the given scenario send-email is completely irrelevant.
Ciao,

Dscho
--

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

--

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