UPDATE: should be fixed in the next release (1.18.8).
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
- 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.
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
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
etckeeper commit will fail if and only if
user.email is not set in
- 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).