Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.

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