Git Log History

Question

One thing that is important with version control is knowing who made what change. If something was changed and I had no idea why the change was made, I would look in the history and ask the person who made the change. As I am exploring git, one thing that makes me a little nervous about this feature is that it seems really easy to fake. What is stopping me from putting a co-workers name/email in the git global config for user.name and user.email? When using something like gitosis/gitolite (which defined users) or github (which I assume using something like gitosis/gitolite), is there any wyy to see who truly made a commit?

Seeseebeck

It's really sad when you can't trust your coworkers... – Ifc

I'm not saying that I would or think any of my co-workers would but unfortunately someone people are not honest (even the ones you think are) – Seeseebeck

Answer 1

Gitolite logs (in .gitolite/logs/gitolite-*) the Gitolite user for each push. There is a bit more work to determine the push that introduced a particular commit, but it should be straight forward (one way: drop light-weight tags at the tip of each push, then use git name-rev to find the first tag after the commit).

Most Gitolite users probably only have a single SSH key associated with them (keydir/user.pub), but it is possible for a single user to have multiple SSH keys (keydir/user@*.pub).

So, for SSH-based Gitolite, you can map each commit to one (or more) SSH keys.

Whether you trust an SSH key to accurately identify a particular person is another question (i.e. do you trust the users to keep their private SSH keys secure?).

Gitolite can also moderate Git access over “smart HTTP”. In that case, the web server supplies the Gitolite username in the REMOTE_USER environment variable (i.e. instead of using the .ssh/authorized_keys file to identify the user based on the SSH key). The identification and authentication is completely up to the web server itself (usually just a username and password, but per-user SSL certificates could be used to do something more like SSH-based access).

So, for HTTP-based Gitolite, you can map each commit to an authentication done by the web server.

---

GitHub has some similar information and that can be queried through the Events part of the GitHub API (previously it only seemed to be available as part of the “Newsfeed” entries for your watched repositories). Each PushEvent identifies the GitHub user that executed the push, the name of the ref (branch) was updated, the name (SHA1 hash) of the new ref “head” (the new tip of the updated branch), and a list of commits.

Therefor

Answer 2

This is not a ethics or philosophy forum, afaik; BUT

git allows signed commits and signed tags. This should help you feed your paranoia :)

Lidless

Answer 3

You can have everybody sign commits with GPG: see this tutorial.

In the tutorial the GPG passphrase is set in git config, which seems nonsense to me, so you'll want to have the hook prompt the user at each commit.

Of course if you're not the manager, proposing that everyone sign their commits can be diplomatically tough, so be prudent.

EDIT: As Brian points out, this only signs the commit message, so it's not the good solution. I keep the answer as it might still help to understand the problem.

Valuer

That post you link to is completely the wrong way to sign commits. It signs only the commit message, not the commit itself, meaning that anyone who wanted to impersonate someone else would just have to reuse their commit message. Also, as you point out, it recommends keeping your passphrase in the clear. Signing commits is generally much more of a pain than it's worth, especially once you start dealing wth issues like rebasing, applying patches from email, and the like. – Examinant