> * If AUTHOR_NAME+EMAIL is different from AUTHOR_NAME+EMAIL that > I would normally get for myself, or I thought of this, however if the purpose of this is to handle a case where you do a commit from a new and unconfigured user account, "that I would normally get for myself" is undefined, since this information is (rightfully) not propagated by git-clone. This is why I made it unconditional, (or perhaps something you could could turn off, but would by default be on), but I figured there would be objections since I admit it's not always useful information. > * If AUTHOR_NAME+EMAIL contains garbage identifier commonly > found when misconfigured (e.g. ".(none)" at the end of > e-mail), That's more interesting to me. I just checked my logs and I do see that in at least one case, this .(none) was not appended. The computer in question was configured (not by me) with a domain of ".local", so the commit has <machinename>.local as part of the email address. However I would imagine this might solve most cases. I still don't understand why git generates a default email address instead of just giving an error message; do people actually use this scenario? In my experience an email address must always be explicitly given, but perhaps some people work on the machines that also receive their mail. I rarely do "real" work on an actual server, but I guess some people do. I think they must be in the minority though.. On the other hand, now that I've been thinking about it I think my idea of simply configuring a hook in my personal central git is probably an easier and all-round better solution to my problem. I understand that git relies on system accounts for security, but there's no reason I can't configure a particular repo to issue a warning when it receives incoming commits from an unknown user/email. Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
