"Stephen Sinclair" [off-list ref] writes:
quoted
* 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).
quoted
* 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.
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
On Fri, Jan 11, 2008 at 05:53:12PM -0800, Junio C Hamano wrote:
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.
I think there are plenty of reasons for the host/gecos information not
being useful. Is a workstation whose hostname is not a valid mailing
address really not "done properly"?
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.
This is obviously not 1.5.4 material, so I haven't given it that much
thought either. But perhaps Stephen's "author message" should simply
trigger any time the author is pulled from gecos? I suppose that would
annoy people who use this feature all the time, but they can silence the
"warning" with a simple git-config.
-Peff