UPDATE: should be fixed in the next release (1.18.8).
https://etckeeper.branchable.com/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances/
After hitting this a couple of times, I felt I needed to look at the source code.
- git absolutely requires an "email address" for its commits. Without one, it will refuse to make a commit.
- git will "autodetect" an email, if the system hostname can be resolved to a Fully Qualified Domain Name. (You must have at least one
. to qualify :). Or, if /etc/mailname exists, it uses that by preference, without checking for .s.
- etckeeper tries to pass an email address to git, constructed from a username and the system hostname. git will accept such explicitly-specified emails, even if the host part is not an FQDN. If
sudo is used, etckeeper uses SUDO_USER from the environment. In case su is used, there is nothing in the environment, and so etckeeper reads the user from the owner of the tty.
So git commit and etckeeper vcs commit failed, when I hadn't set user.email, AND my hostname did not resolve to an FQDN.
etckeeper commit works in some situations that git commit doesn't. I believe I got confused between these two when I was testing before (among other things).
If you run etckeeper from sudo, it won't fail. If you run it from su, it won't fail. It won't fail either if you log in as root and run it; it will find a tty which is owned by root, and pass an email of root@HOSTNAME.
etckeeper commit will fail if and only if
user.email is not set in git, AND
- the system hostname cannot be resolved to an FQDN, AND
- /etc/mailname does not exist (it is created by the Debian exim packages?) AND
- etckeeper is not run from sudo AND
- etckeeper is not run from a tty
Finally, testing indicated that commands run under ansible are never run from a tty. (Even when using an ssh connection and sudo with a password, where ansible is described as needing to use a pseudo-tty).