"Stephen Sinclair" <radarsat1@xxxxxxxxx> writes: >> * 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. What are you talking about? In a properly configured repository, telling you who git thinks you are is _ALWAYS_ useless (that's the definition of "properly configured"). Just admit it. The only case it is of any use is to remind people who amend other people's change. Showing the AUTHOR for the commit being created would add value (and the knowledge that git shows AUTHOR in that situation would help remind you that it will be recording your own name if you do not see that line). >> * 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. Yes, and please notice that "e.g." in my description means "I am just giving you an example, not the exhaustive list for the final solution but a hint to one possibly acceptable solution". ".local", "@localhost", "@<distroname>" and ".(none)" are all plausible red-flag raisers. There may be more, but I think we should be able to catch most misconfigurations with simple rules. > 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? The official party line to defend the existing behaviour is that there is no need to configure anything, when the host and gecos is done properly. But I tend to agree with you that quite a lot of systems are not "done properly", and users cannot do much about it in some cases. I think most of misconfigured systems are personal boxes they have control over but not all. Perhaps we could disable the code that reads from hostname and gecos, and instead always force the users to configure. But that kind of change is not something I'd want to be discussing right now. - 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
