> 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. Well, I'll admit that I don't really understand you here. Maybe I'm still too much of a git newbie on this. (Fair enough.) Right now the only way to make sure I'm committing as myself with my proper email address is to: -- remember to "git-config --list", and check that my email is listed. -- "git-commit; git-log", and remember to check the last entry before doing a "git-push". Am I missing something? If proper use of git seems to require remembering one of these two things, that's okay with me, I'll just do my best, but it was an area where I thought I might suggest an improvement. (As a rule, I prefer letting the computer remember things for me.) > ".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'd have to disagree with you here. Most people name their boxes one thing or another, and trying to catch it with some rule is pointless. Especially considering the default name is taken from the hostname anyway -- you're taking the local hostname and then checking with a rule to see if it might be localhost. Personally I think the solution is not to take the hostname in the first place, since in my experience it's rarely equivalent to a valid email address. Obviously though my personal experience is apparently not the same as that of others'. I do most of my development on personal boxes, or laptops configured by some non-professional guy in my lab at university. Or on virtual machines, which was my recent case. > Perhaps we could disable the code that reads from hostname and > gecos, and instead always force the users to configure. That would be my preference, and I do think there's a case for it. But whether it's a strong one or not I'm not sure. > But that kind of change is not something I'd want to be > discussing right now. That's okay. In the spirit of git, I'll just solve my problem in my own branch.. ;-) thanks for the comments, 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
