Currently, the vcs subcommand does not export environment variables in the same way that the commit subcommand does. It can be useful to have those environment variables in some cases, though, such as when you're using git and wanting to run a revert subcommand (e.g. with $ sudo etckeeper vcs revert $REVISION), as the revert functionality includes committing the reverted change.
I submit this pull request as a possible strategy to implement this: it currently duplicates the environment export logic from the commit subcommand. It might make sense to refactor this out into some sort of library, but I'm not really familiar enough with shell script project conventions (or the maintainer's style goals) to suggest a strategy for this.
Looking back at [[!commit 65eda73020e0aa6bf15e64106dae955bf17a41dd]], the initial idea of
etckeeper vcswas to run the command in the same environment that etckeeper uses. Which it does do forHOMEand a few other things.So I'm broadly in agreement that this might be a good idea. But copying 86 lines of quite hairy code is certainly not a maintainable way to do it.
There's also the question of whether a user might be surprised to find specific things that happen to be set in the
etckeeper commitenvironment being set.Also worth bearing in mind that
etckeeper commitneeds to run successfully even if the host doesn't have a hostname configured or in the face of other problems that typically prevent git from committing. Because it's run by eg apt hooks, and generally is an abstraction layer where the user may not be comfortable setting up git. That does not really apply toetckeeper vcs, and so a certian amount of the code frometckeeper commitdoesn't seem necessary inetckeeper vcs.(Also you have this line that was accidentially left in: echo "Testing; \$USER: $USER"` )