Carlos Martín Nieto <cmn@xxxxxxxx> writes: > That's not how it works. It may even be possible to rewrite the commits > in the post-receive hook in a way that most stuff doesn't break > horribly, this would be rewriting history behind the users' backs, and > that only brings problems. What you can do is forbid push. I think update-paranoid and gitolite have some examples on how to do that. > The way to set the author name and mail in a standard way, be it > user-wide or per-repo. You can write up some simple instructions on how > to do it. > > git config user.name "Max Smith" > git config user.mail max.smith@xxxxxxxxxxx > > and if the config should be valid for every repo, use --global flag. > There is more information in the manual page. > > You could then add a check in the post-receive hook to reject pushes > with invalid author names, if you feel it's worth it. > > Taking a step back, why is this even an issue, though? If you don't > trust your developers to set their name and email correctly, why do you > trust them to write code? If it's company policy for people to be > referred to by their usernames rather than their given names, why not > tell them to set it to that[0]? It seems like you are trying to solve a > social issue with a technological measure that works at a different > level. > > [0] and given that they're probably using their company email address, > it wouldn't be a problem to get a unique ID for each developer if that's > what you need. Note that there is also .mailmap mechanism (see the documentation) which can translate on the fly between public emails and internal company emails, and which can fix invalid names... at least got git-log, git-blame etc. -- Jakub Narębski -- 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