Recent changes to this wiki:

Added a comment: Cannot version files in .hg directory
diff --git a/doc/forum/path_contains_illegal_component/comment_1_592f81618dde9f37c45ab7b0dd6baa8f._comment b/doc/forum/path_contains_illegal_component/comment_1_592f81618dde9f37c45ab7b0dd6baa8f._comment
new file mode 100644
index 0000000..32564c8
--- /dev/null
+++ b/doc/forum/path_contains_illegal_component/comment_1_592f81618dde9f37c45ab7b0dd6baa8f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="etckeep@4f7bb5e4e71942aea2d70a344bc1ffc3d17e33b8"
+ nickname="etckeep"
+ avatar="http://cdn.libravatar.org/avatar/bedda0cf35898e15636d0f594ef83335"
+ subject="Cannot version files in .hg directory"
+ date="2020-10-12T00:01:30Z"
+ content="""
+There is a setting in /etc/etckeepeer.conf like so:
+# Uncomment the following to avoid special file warning
+# (the option is enabled automatically for daily autocommits regardless).
+AVOID_SPECIAL_FILE_WARNING=1
+
+It is commented out by default because of the automatic enabling, but I have enabled it to see wheterh it makes a difference.
+"""]]

diff --git a/doc/forum/path_contains_illegal_component.mdwn b/doc/forum/path_contains_illegal_component.mdwn
index 7d6d513..23e2287 100644
--- a/doc/forum/path_contains_illegal_component.mdwn
+++ b/doc/forum/path_contains_illegal_component.mdwn
@@ -11,3 +11,8 @@ I attempted to install a more recent version of hg from a ppa repository, but I
 
 I eventually upgraded hg using pip install, and I now have 5.5.2 and that seems to have fixed the problem.
 
+I spoke too soon.
+
+For testing purposes, I moved cron.daily/etckeeper to cron.hourly.
+
+The error does not occur every hour, so there is some dependency on the path taken through the various etckeeper scripts.

diff --git a/doc/forum/path_contains_illegal_component.mdwn b/doc/forum/path_contains_illegal_component.mdwn
new file mode 100644
index 0000000..7d6d513
--- /dev/null
+++ b/doc/forum/path_contains_illegal_component.mdwn
@@ -0,0 +1,13 @@
+After upgrading one of my servers from Ubuntu 16.04 to 18.04, I started to receive error messages from the etckeeper cron.daily job.
+
+/etc/cron.daily/etckeeper:
+abort: path contains illegal component: .hg/undo.dirstate
+abort: path contains illegal component: .hg/undo.backup.dirstate
+
+Note that I use mercurial for etckeeper. (I use hg in preference to git wherever I have the option.)
+A search for the error message showed some very old error associated with hg.
+
+I attempted to install a more recent version of hg from a ppa repository, but I don't think that was successful. (I can't be more definite than that.) At any rate, the apt version of hg is 4.5.3-1ubuntu2.1
+
+I eventually upgraded hg using pip install, and I now have 5.5.2 and that seems to have fixed the problem.
+

diff --git a/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__.mdwn b/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__.mdwn
new file mode 100644
index 0000000..bc4defa
--- /dev/null
+++ b/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__.mdwn
@@ -0,0 +1,31 @@
+Whenever I try to install something on CentOS (release 7.8.2003, installed via epel) etckeeper pre/auto commit ll get stuck mostly on pre commit. 
+I also got one server where post commit fails me, but on there one I can just abort the command. 
+
+```
+
+Transaction Summary
+===================================================================================================================================================================
+Upgrade  11 Packages
+
+Total size: 835 M
+Downloading packages:
+Running transaction check
+Running transaction test
+Transaction test succeeded
+Running transaction
+etckeeper: pre transaction commit
+^[[A^[[A^
+``` 
+
+
+```
+yum-3.4.3-167.el7.centos.noarch
+yum-utils-1.1.31-54.el7_8.noarch
+yum-plugin-fastestmirror-1.1.31-54.el7_8.noarch
+yum-metadata-parser-1.1.4-10.el7.x86_64
+etckeeper-1.18.14-1.el7.noarch
+git-1.8.3.1-23.el7_8.x86_64
+
+```
+
+For now, the workaround is to disable the yum-plugin with the config file /etc/yum/pluginconf.d/etckeeper.conf 

comment
diff --git a/doc/forum/etckeeper_wants_root_git_identity/comment_3_88c973d26858bec68055fcd3d35268d6._comment b/doc/forum/etckeeper_wants_root_git_identity/comment_3_88c973d26858bec68055fcd3d35268d6._comment
new file mode 100644
index 0000000..22786da
--- /dev/null
+++ b/doc/forum/etckeeper_wants_root_git_identity/comment_3_88c973d26858bec68055fcd3d35268d6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-08-10T21:27:43Z"
+ content="""
+[[install]] says where the git repo is. (Not on github.)
+"""]]

uuuuh
diff --git a/doc/forum/Does_not_create_config/comment_2_f6bdb049f8090fe7f1fbf827f793ef10._comment b/doc/forum/Does_not_create_config/comment_2_f6bdb049f8090fe7f1fbf827f793ef10._comment
new file mode 100644
index 0000000..58bd6eb
--- /dev/null
+++ b/doc/forum/Does_not_create_config/comment_2_f6bdb049f8090fe7f1fbf827f793ef10._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-07-20T23:42:10Z"
+ content="""
+It would probably be helpful if you explained how you installed it, if you
+want help with that.
+
+The file is:
+
+* installed by "make install"
+* included in the debian package
+* included in the source repository as "etckeeper.conf"
+"""]]

Added a comment: edit
diff --git a/doc/forum/Does_not_create_config/comment_1_295ecd7681224829e833536203269129._comment b/doc/forum/Does_not_create_config/comment_1_295ecd7681224829e833536203269129._comment
new file mode 100644
index 0000000..6141109
--- /dev/null
+++ b/doc/forum/Does_not_create_config/comment_1_295ecd7681224829e833536203269129._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="katja.decuir@4e7c83f07a1d91a09af5d3eb1c954d7e0f5bae3a"
+ nickname="katja.decuir"
+ avatar="http://cdn.libravatar.org/avatar/133a3d2faf199a882a1ad990659907a0"
+ subject="edit"
+ date="2020-07-11T08:51:50Z"
+ content="""
+i can't even find a default config to copypaste on google. all those websites say \"default is fine\" but i dont even have default and the readme on the website isn't helpful
+"""]]

diff --git a/doc/forum/Does_not_create_config.mdwn b/doc/forum/Does_not_create_config.mdwn
new file mode 100644
index 0000000..f6359fd
--- /dev/null
+++ b/doc/forum/Does_not_create_config.mdwn
@@ -0,0 +1 @@
+I've just installed etckeeper however there is no /etc/etckeeper/etckeeper.conf file and no default config. i can't remove it with apt now either because it complains it needs a VCS set up in the config file.. which doesn't exist. how can i fix this? i need to be able to use apt to update, install and remove stuff.. i can't even use it because of this VCS thing

comment
diff --git a/doc/forum/Comparing___47__etcs/comment_2_2b2d1a57ad72a1196f0d2a2d546b0c2e._comment b/doc/forum/Comparing___47__etcs/comment_2_2b2d1a57ad72a1196f0d2a2d546b0c2e._comment
new file mode 100644
index 0000000..412b87d
--- /dev/null
+++ b/doc/forum/Comparing___47__etcs/comment_2_2b2d1a57ad72a1196f0d2a2d546b0c2e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-26T23:09:08Z"
+ content="""
+git diff does not care one bit if the branches are related or not.
+(git merge does care, but it can be overridden with
+--allow-unrelated-histories)
+
+It may be that gitea has some check in its UI to avoid diffing related
+braches for some reason.
+"""]]

Added a comment
diff --git a/doc/forum/Comparing___47__etcs/comment_1_7a417a317cf5fbc78924575dc7b5e32b._comment b/doc/forum/Comparing___47__etcs/comment_1_7a417a317cf5fbc78924575dc7b5e32b._comment
new file mode 100644
index 0000000..c6a1ec2
--- /dev/null
+++ b/doc/forum/Comparing___47__etcs/comment_1_7a417a317cf5fbc78924575dc7b5e32b._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="sshaikh"
+ avatar="http://cdn.libravatar.org/avatar/e31e0ba78d2df04dc252e1bf87e8f378"
+ subject="comment 1"
+ date="2020-05-23T14:58:39Z"
+ content="""
+I think this does what I need:
+
+    #use a temp dir
+    mkdir /tmp/etc
+    cd /tmp/etc
+    git init
+    git remote add origin http://git.server/user/server_etc.git
+    touch init
+    git add .
+    git commit -m \"init\"
+    git push --set-upstream origin master
+    git fetch
+    git checkout host-one
+    git rebase master
+    #lots of merge errors due to master being empty repo
+    git add .
+    git rebase --continue
+    git push --force #as local is now \"ahead\" of remote.
+"""]]

diff --git a/doc/forum/Comparing___47__etcs.mdwn b/doc/forum/Comparing___47__etcs.mdwn
new file mode 100644
index 0000000..444557d
--- /dev/null
+++ b/doc/forum/Comparing___47__etcs.mdwn
@@ -0,0 +1,24 @@
+I have two hosts which have been set up identically, except for a few things like hostnames and the like. I also have a git server (gitea) separate from both. I set up etckeeper as per the following (running Debian):
+
+    apt install etckeeper
+    cd /etc/
+    git status
+    git diff
+    git commit -m "initial commit"
+    git gc
+    git remote add origin http://git.server/user/server_etc.git
+
+Since I have two hosts, I thought it would be useful/convenient to give each one a named branch in the same repo:
+
+    git branch -m host-one
+    git push --set-upstream origin host-one
+
+And same for host-two.
+
+In gitea I successfully can see the two branches (and there is no master). However git/gitea does not see them as related branches and so will not compare them. This makes sense to me as they were both new branches.
+
+How can I make them related branches, ideally without clobbering my hosts (I'd rather not pull anything on those)?
+
+I think I have to give each branch a common parent (maybe a blank master?), but I'm happy to make host-two a branch of host-one if that's easier.
+
+(I realise this isn't strictly a etckeeper question but I posted here in case it help others with a similar usecase).

Added a comment: Debian patches
diff --git a/doc/todo/python3_support/comment_2_be3f3171c06d1baf0805a26065225414._comment b/doc/todo/python3_support/comment_2_be3f3171c06d1baf0805a26065225414._comment
new file mode 100644
index 0000000..ed52509
--- /dev/null
+++ b/doc/todo/python3_support/comment_2_be3f3171c06d1baf0805a26065225414._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nathanst"
+ avatar="http://cdn.libravatar.org/avatar/1844c7b9b45fdd9049494b4a09b26a49"
+ subject="Debian patches"
+ date="2020-05-13T22:54:12Z"
+ content="""
+I believe the patches referred to are found in this commit (pushed on the same date as this \"python3 support\" page was created):
+<https://git.joeyh.name/index.cgi/etckeeper.git/commit/?h=debian&id=b3f133c5d8cec6f586e021be45efffb3d570021d>
+"""]]

Added a comment
diff --git a/doc/forum/etckeeper_wants_root_git_identity/comment_2_9042f537f95e45e35aba9fa37459e2ee._comment b/doc/forum/etckeeper_wants_root_git_identity/comment_2_9042f537f95e45e35aba9fa37459e2ee._comment
new file mode 100644
index 0000000..2858a39
--- /dev/null
+++ b/doc/forum/etckeeper_wants_root_git_identity/comment_2_9042f537f95e45e35aba9fa37459e2ee._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="psydev"
+ avatar="http://cdn.libravatar.org/avatar/b841d7f8d20a92d96cb4e6407f7ac7a1"
+ subject="comment 2"
+ date="2020-05-10T09:46:37Z"
+ content="""
+I've hit the same issue, it seems to be due to `50vcs-commit` not setting `GIT_COMMITTER_NAME`.
+
+I've fixed it with the following patch:
+>     --- /home/psydev/Documents/50vcs-commit.orig	2020-05-10 11:24:46.678103463 +0200
+>     +++ /etc/etckeeper/commit.d/50vcs-commit	2020-05-10 11:19:26.710380696 +0200
+>     @@ -54,22 +54,26 @@
+>      		if [ -n \"$USER_HOME\" ] && [ -e \"$USER_HOME/.gitconfig\" ]; then
+>      			if [ -z \"$GIT_AUTHOR_NAME\" ]; then
+>      				GIT_AUTHOR_NAME=\"$(git config -f \"$USER_HOME/.gitconfig\" user.name)\" || true
+>     -				export GIT_AUTHOR_NAME
+>     +				GIT_COMMITTER_NAME=\"$GIT_AUTHOR_NAME\"
+>     +				export GIT_AUTHOR_NAME GIT_COMMITTER_NAME
+>      			fi
+>      			if [ -z \"$GIT_AUTHOR_EMAIL\" ]; then
+>      				GIT_AUTHOR_EMAIL=\"$(git config -f \"$USER_HOME/.gitconfig\" user.email)\" || true
+>     -				export GIT_AUTHOR_EMAIL
+>     +				GIT_COMMITTER_EMAIL=\"$GIT_AUTHOR_EMAIL\"
+>     +				export GIT_AUTHOR_EMAIL GIT_COMMITTER_EMAIL
+>      			fi
+>      		fi
+>      		if [ -z \"$GIT_AUTHOR_NAME\" ] || [ -z \"$GIT_AUTHOR_EMAIL\" ]; then
+>      			if [ -n \"$USER_HOME\" ] && [ -e \"$USER_HOME/.config/git/config\" ]; then
+>      				if [ -z \"$GIT_AUTHOR_NAME\" ]; then
+>      					GIT_AUTHOR_NAME=\"$(git config -f \"$USER_HOME/.config/git/config\" user.name)\" || true
+>     -					export GIT_AUTHOR_NAME
+>     +					GIT_COMMITTER_NAME=\"$GIT_AUTHOR_NAME\"
+>     +					export GIT_AUTHOR_NAME GIT_COMMITTER_NAME
+>      				fi
+>      				if [ -z \"$GIT_AUTHOR_EMAIL\" ]; then
+>      					GIT_AUTHOR_EMAIL=\"$(git config -f \"$USER_HOME/.config/git/config\" user.email)\" || true
+>     -					export GIT_AUTHOR_EMAIL
+>     +					GIT_COMMITTER_EMAIL=\"$GIT_AUTHOR_EMAIL\"
+>     +					export GIT_AUTHOR_EMAIL GIT_COMMITTER_EMAIL
+>      				fi
+>      			fi
+>      		fi
+The formatting rules on this wiki gave me more trouble than the fix though... ;)
+
+Where/how can I contribute this? I've seen multiple github repos, can the author point me to the correct place? Thanks
+"""]]

comment
diff --git a/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/comment_2_48e36e7c4b88b27129650e9c447a374c._comment b/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/comment_2_48e36e7c4b88b27129650e9c447a374c._comment
new file mode 100644
index 0000000..6772b36
--- /dev/null
+++ b/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/comment_2_48e36e7c4b88b27129650e9c447a374c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-05T20:38:57Z"
+ content="""
+Gave this a try, and the nested repo gets commited as a submodule, which
+makes a certain amount of sense. But /etc/.etckeeper includes directories
+and files inside the rested repo, including even in its .git/ directory.
+
+The way pre-commit.d/30store-metadata finds files, and empty
+subdirectories, would need to be changed to take nested git repos into
+account. I don't immediately see a good way.
+"""]]

more frequent gc
If gc.auto is not configured, override the default to make it gc ten times
more frequently, to avoid wasting space with loose objects.
This commit was sponsored by Ryan Newton on Patreon.
diff --git a/commit.d/50vcs-commit b/commit.d/50vcs-commit
index bd4b1d4..ca02479 100755
--- a/commit.d/50vcs-commit
+++ b/commit.d/50vcs-commit
@@ -91,10 +91,18 @@ if [ "$VCS" = git ] && [ -d .git ]; then
 			export GIT_COMMITTER_EMAIL
 		fi
 	fi
+
+	# gc ten times more frequently than the default
+	# (unless some other config is set)
+	GIT_GC_OPTIONS=
+	if ! git config gc.auto >/dev/null; then
+		GIT_GC_OPTIONS="-c gc.auto=670"
+	fi
+
 	if [ -n "$logfile" ]; then
-		git commit $GIT_COMMIT_OPTIONS -F "$logfile"
+		git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F "$logfile"
 	else
-		git commit $GIT_COMMIT_OPTIONS
+		git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS
 	fi
 elif [ "$VCS" = hg ] && [ -d .hg ]; then
 	if [ -n "$USER" ]; then
diff --git a/debian/changelog b/debian/changelog
index fd1d796..1a0b815 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,8 @@ etckeeper (1.18.15) UNRELEASED; urgency=medium
   * Improve commit messages generated by package manager changes,
     listing packages that are responsible for the changed config files.
     Thanks to emkael for the patch.
+  * If gc.auto is not configured, override the default to make it gc
+    ten times more frequently, to avoid wasting space with loose objects.
 
  -- Joey Hess <id@joeyh.name>  Fri, 24 Apr 2020 13:05:59 -0400
 
diff --git a/doc/todo/automatic_git_gc.mdwn b/doc/todo/automatic_git_gc.mdwn
index 1359661..2b285b6 100644
--- a/doc/todo/automatic_git_gc.mdwn
+++ b/doc/todo/automatic_git_gc.mdwn
@@ -2,3 +2,5 @@ Hi
 
 You should add so it runs "git gc" automatic.
 I know I can add it manually but better if its included
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/automatic_git_gc/comment_3_0da657ee0aca64875b1623d52bd17592._comment b/doc/todo/automatic_git_gc/comment_3_0da657ee0aca64875b1623d52bd17592._comment
new file mode 100644
index 0000000..8e115ba
--- /dev/null
+++ b/doc/todo/automatic_git_gc/comment_3_0da657ee0aca64875b1623d52bd17592._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-05T20:07:40Z"
+ content="""
+10x pack improvement is not unusual when running git gc. Just gced my /etc
+from 32mb down to 3.9mb. But that does not tell me that git is not running
+gc often enough in /etc, necessarily.
+
+I think the question is, might the way etckeeper uses git happen to avoid
+the git commands that do auto gc?
+
+After all, the only command run in some etckeeper repos is git commit,
+and some git ls-files and similar query commands.
+
+One command I know triggers an auto gc is git fetch, which is never run.
+
+Looking at git's source code, git commit does seem to run gc --auto.
+Verified that with `GIT_TRACE=1 git commit`
+
+So, it seems to me that if git has not gc'ed a 500 mb repo, it must be
+because the default or system gc.auto config didn't make it want to, not
+that it didn't have the opportunity. If there are less than 6700 objects,
+it by default won't. Suppose there's a 100 kb config file that keeps
+getting modified and commited by etckeeper. 6000 versions of that file
+stored as loose objects would bloat the repo up to 585 mb (well, a bit
+less, git does compress the objects), and would not be enough objects to
+trigger gc.auto. Something like that seems plausible.
+
+What 100 kb config file, you ask? /etc/.etkeeper runs around that large!
+So do my dnssec zone files (which get auto-regenerated regularly).
+
+So, I think it would make sense for etckeeper to set gc.auto to a smaller
+number, say 670.
+"""]]

finally applied an old patch
diff --git a/debian/changelog b/debian/changelog
index f816938..fd1d796 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ etckeeper (1.18.15) UNRELEASED; urgency=medium
   * Use "command -v" rather than "which" to detect installed programs,
     as it is more portable.
     Thanks, Eli Schwartz.
+  * Improve commit messages generated by package manager changes,
+    listing packages that are responsible for the changed config files.
+    Thanks to emkael for the patch.
 
  -- Joey Hess <id@joeyh.name>  Fri, 24 Apr 2020 13:05:59 -0400
 
diff --git a/doc/todo/Detailed_post-install_commit_messages.mdwn b/doc/todo/Detailed_post-install_commit_messages.mdwn
index 517506f..076ee52 100644
--- a/doc/todo/Detailed_post-install_commit_messages.mdwn
+++ b/doc/todo/Detailed_post-install_commit_messages.mdwn
@@ -7,3 +7,5 @@ I find it useful on large system updates, when the package list gets long and co
 I have to note that I don't use package managers other than apt/rpm or vcs other than git on regular basis, so it would be useful if someone with more experience on those takes a look at mercurial/bazaar/darcs and pacman/pkgng implementations of the functions.
 
 Patch for the post-install.d/50vcs-commit file is available at: <https://gist.github.com/emkael/364f701a5342978e6e79c2368b905565>
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/Detailed_post-install_commit_messages/comment_5_d63d5c8b4a8a928c1edd0d5ef24bd538._comment b/doc/todo/Detailed_post-install_commit_messages/comment_5_d63d5c8b4a8a928c1edd0d5ef24bd538._comment
new file mode 100644
index 0000000..b87a709
--- /dev/null
+++ b/doc/todo/Detailed_post-install_commit_messages/comment_5_d63d5c8b4a8a928c1edd0d5ef24bd538._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-05-05T20:04:18Z"
+ content="""
+Seems I forgot all about this for 4 years, oops.
+
+Good thing is, the patch still applied with only a few changes, so it's in,
+finally. Thank you.
+"""]]

remove empty comment
diff --git a/doc/todo/Detailed_post-install_commit_messages/comment_3_f6b7ece8bb96a69d1fbc4e3abf12929f._comment b/doc/todo/Detailed_post-install_commit_messages/comment_3_f6b7ece8bb96a69d1fbc4e3abf12929f._comment
deleted file mode 100644
index 6b9cd75..0000000
--- a/doc/todo/Detailed_post-install_commit_messages/comment_3_f6b7ece8bb96a69d1fbc4e3abf12929f._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2016-10-21T19:13:48Z"
- content="""
-
-"""]]

close
diff --git a/doc/todo/running___96__find_.__96___in___47___prints_warnings.mdwn b/doc/todo/running___96__find_.__96___in___47___prints_warnings.mdwn
index 94a6733..1a10217 100644
--- a/doc/todo/running___96__find_.__96___in___47___prints_warnings.mdwn
+++ b/doc/todo/running___96__find_.__96___in___47___prints_warnings.mdwn
@@ -13,3 +13,10 @@ Due to files in `/proc` being created and deleted while `find` is running.
 
 
 I am not sure why `find` needs to run at all, when instead one could analyze the output of git ls-files and see if any of those files are problematic.
+
+> Using etckeeper to track all of `/` is not a supported use case.
+> You're free to try to use etckeeper that way, but when it breaks, you get
+> to modify it to work yourself, and it seems unlikely that the resulting
+> patches would be suitable to be applied to etckeeper. 
+>
+> So [[wontfix|done]], sorry. --[[Joey]]

close
diff --git a/doc/todo/30store-metadata_stores_metadata_for_untracked_files.mdwn b/doc/todo/30store-metadata_stores_metadata_for_untracked_files.mdwn
index f093b08..4366cd5 100644
--- a/doc/todo/30store-metadata_stores_metadata_for_untracked_files.mdwn
+++ b/doc/todo/30store-metadata_stores_metadata_for_untracked_files.mdwn
@@ -1,3 +1,5 @@
 I am trying to use etckeeper to track `/`  (We need to track /etc and also /unionfs/overlay/etc, which is an etc that gets loaded onto a second computer).
 
 `git ls-files` lists only the files we want to track, and `.gitignore` correctly excludes all the files we don't want to match (such as `./home`, `./proc`, ), yet somehow `.etckeeper` contains metadata for a bunch of files that I don't want etckeeper to touch.
+
+> [[done]] not a supported way to use etckeeper. --[[Joey]]
diff --git a/doc/todo/30store-metadata_stores_metadata_for_untracked_files/comment_1_c928791835e1d53cc42088ef6574e24c._comment b/doc/todo/30store-metadata_stores_metadata_for_untracked_files/comment_1_c928791835e1d53cc42088ef6574e24c._comment
new file mode 100644
index 0000000..5645f55
--- /dev/null
+++ b/doc/todo/30store-metadata_stores_metadata_for_untracked_files/comment_1_c928791835e1d53cc42088ef6574e24c._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-05T19:36:16Z"
+ content="""
+I don't support using etckeeper to version control stuff other than /etc.
+
+30store-metadata gets a list of all fils git is configured to ignore,
+and then runs a find and uses grep to exclude files in that list.
+
+I've verified this seems to work ok when etckeeper is used the usual way in
+/etc. Something about the non-supported way you're using etckeeper must be
+causing the problem.
+
+Perhaps git ls-files -oi --exclude-standard
+when run in / somehow doesn't list every single file in your entire
+computer, for whatever reason. When I tried putting a git repo in /.git/
+and running that, it hung for a long time.
+
+Sorry, I'm going to close this.
+"""]]

close
diff --git a/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn b/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn
index 48de821..af05b54 100644
--- a/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn
+++ b/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn
@@ -8,3 +8,5 @@ Error: Package: etckeeper-1.18.7-2.el6.noarch (epel)
 
 
 OS version: CentOS release 6.9 (Final)
+
+> [[notabug|done]] --[[Joey]]

comments
diff --git a/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd/comment_1_d5620588716a2dc82bc6372482eaaca6._comment b/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd/comment_1_d5620588716a2dc82bc6372482eaaca6._comment
new file mode 100644
index 0000000..be55869
--- /dev/null
+++ b/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd/comment_1_d5620588716a2dc82bc6372482eaaca6._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-05T18:46:14Z"
+ content="""
+Well, this seems like quite a mess at first glance.
+
+The commit that added the timer claims that the timer is not enabled
+by default. If the timer is enabled by default, then everything that was
+done to intergrate it seems like it must rest on a faulty foundation.
+
+Afaik, systemd does not enable a unit just because the file is dropped into
+/lib/systemd; it has to be enabled. So what is enabling it?
+
+I checked a few systems, and they all had the timer enabled due to
+/etc/systemd/system/multi-user.target.wants/etckeeper.timer
+existing. git log seems to indicate the file got created before
+etckeeper's first commit to /etc. I do not know what creates it.
+
+It seems to me we need to understand the root cause of what is enabling
+that to fix it.
+
+The patch in 883263 adds some ugliness to the cron job to check if the
+timer is enabled. The patch 884824 in makes `AVOID_DAILY_AUTOCOMMITS`
+prevent the timer from committing. The way this is supposed to work is
+documented in etckeeper.conf:
+
+	# Etckeeper includes both a cron job and a systemd timer, which each
+	# can commit exiting changes to /etc automatically once per day.
+	# To enable the systemd timer, run: systemctl enable etckeeper.timer
+	# The cron job is enabled by default; to disable it, uncomment this next line.
+	#AVOID_DAILY_AUTOCOMMITS=1
+
+The second patch would make that documentation be incorrect because
+it would also start disabling the timer. The first
+patch should not be necessary if that documentation is followed, except
+for the problem that the timer is apparently being wrongly enabled by default.
+
+So I would rather understand and fix the root cause than patch over it in ways
+that add complexity and change the meaning of existing configurations.
+
+(Alternatively, could just remove the cron job, remove `AVOID_DAILY_AUTOCOMMITS`
+and let the timer be disabled if the user doesn't want it, but that
+would need some explicit, understood mechanism that enables the timer.
+Or could just remove the timer.)
+"""]]
diff --git a/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd/comment_2_a225ebacd104f793dcffe08ec5ab880d._comment b/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd/comment_2_a225ebacd104f793dcffe08ec5ab880d._comment
new file mode 100644
index 0000000..3336b14
--- /dev/null
+++ b/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd/comment_2_a225ebacd104f793dcffe08ec5ab880d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-05T19:16:58Z"
+ content="""
+I tried, as an experiment, adding a copy of etckeeper.service and
+etckeeper.timer with a different name (netkeeper).
+
+They were not enabled after writing the files, or after a systemctl
+daemon-reload. I even tried rebooting, and they're still not enabled.
+
+Next experiment: I uninstalled etckeeper and deleted the symlink in /etc for
+its timer. systemd no longer had the timer enabled. I then reinstalled it
+with apt. systemd still didn't have the timer enabled, the symlink did not
+come back. (Even after rebooting.)
+
+So, I'd think that there is no bug at all, except I am seeing the timer be
+enabled by that symlink on multiple machines, including a machine that I'm
+positive I've deployed entirely from configuration management. And I'm
+pretty sure I never manually enabled it on any of the machines I see it
+enabled on.
+
+Maybe something used to cause the timer to get auto-enabled and no longer
+does?
+"""]]

comment
diff --git a/doc/forum/etckeeper_wants_root_git_identity/comment_1_b7f0c09b843edebfa06117c660b8a9d3._comment b/doc/forum/etckeeper_wants_root_git_identity/comment_1_b7f0c09b843edebfa06117c660b8a9d3._comment
new file mode 100644
index 0000000..0e6d3ae
--- /dev/null
+++ b/doc/forum/etckeeper_wants_root_git_identity/comment_1_b7f0c09b843edebfa06117c660b8a9d3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-05T18:36:14Z"
+ content="""
+I don't know. The code that does it is in /etc/etckeeper/commit.d/50vcs-commit 
+
+AFAICS, unless sudo does not set `SUDO_USER` (which it usually does) 
+or "whoami" does not output a username, that code *always* sets
+`GIT_AUTHOR_NAME` etc, which avoid git failing in that way.
+"""]]

comment
diff --git a/doc/todo/python3_support/comment_1_681d64c82b63eb4c1bab369b9a640787._comment b/doc/todo/python3_support/comment_1_681d64c82b63eb4c1bab369b9a640787._comment
new file mode 100644
index 0000000..f00562e
--- /dev/null
+++ b/doc/todo/python3_support/comment_1_681d64c82b63eb4c1bab369b9a640787._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-05T18:33:40Z"
+ content="""
+It's not clear to me what commits you're referring to, or where I can get
+them.
+"""]]

python3 patches available in debian/patches in the debian branch
diff --git a/doc/todo/python3_support.mdwn b/doc/todo/python3_support.mdwn
new file mode 100644
index 0000000..49e8a51
--- /dev/null
+++ b/doc/todo/python3_support.mdwn
@@ -0,0 +1,7 @@
+etckeeper doesn't support python3 in its current form. in [bug 811180](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811180), mattia provided a NMU that fixed this, but unfortunately I totally forgot to include it in the later uploads so it got destroyed.
+
+i have now remerged it in the debian branch, and you now have patches there to review to make etckeeper (or, more specifically, the bzr plugin) survive the Python 2 dead parrot stage.
+
+there's also another patch there to fix sort order with UTF-8 which I do not understand very well, but i hope you will find useful.
+
+thanks! -- [[anarcat]]

Use "command -v" rather than "which" to detect installed programs, as it is more portable. Thanks, Eli Schwartz.
diff --git a/debian/changelog b/debian/changelog
index d3f08a1..f816938 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+etckeeper (1.18.15) UNRELEASED; urgency=medium
+
+  * Use "command -v" rather than "which" to detect installed programs,
+    as it is more portable.
+    Thanks, Eli Schwartz.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 24 Apr 2020 13:05:59 -0400
+
 etckeeper (1.18.14) unstable; urgency=medium
 
   * pacman 5.2 deprecated File hooks, use Path.
diff --git a/doc/todo/Use_portable_command_-v.mdwn b/doc/todo/Use_portable_command_-v.mdwn
index 31f1dc5..20ea775 100644
--- a/doc/todo/Use_portable_command_-v.mdwn
+++ b/doc/todo/Use_portable_command_-v.mdwn
@@ -24,3 +24,5 @@ Eli Schwartz (1):
  vcs.d/50vcs-cmd                 | 2 +-
  7 files changed, 9 insertions(+), 9 deletions(-)
 ```
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/Use_portable_command_-v/comment_1_75d97a77ffdccc3be06940f68b2b6ac1._comment b/doc/todo/Use_portable_command_-v/comment_1_75d97a77ffdccc3be06940f68b2b6ac1._comment
new file mode 100644
index 0000000..2fd78ef
--- /dev/null
+++ b/doc/todo/Use_portable_command_-v/comment_1_75d97a77ffdccc3be06940f68b2b6ac1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-24T16:43:02Z"
+ content="""
+The way this was presented left me at sea about the rationalle for the change.
+I had to read the commit message (which was excellent) to understand.
+
+Surprising to me that posh is apparently out of date on standards, and I
+could not find a bug report on it to get it updated either. However, 
+I was quickly able to find command -v use in scripts on a debian system, so
+anyone using posh as their system shell is already experiencing other breakage.
+So no worries on that front. Applying as-is.
+"""]]

response
diff --git a/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__/comment_1_2e638229f7460b34ded7d5dec9f24ef6._comment b/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__/comment_1_2e638229f7460b34ded7d5dec9f24ef6._comment
new file mode 100644
index 0000000..b00a24c
--- /dev/null
+++ b/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__/comment_1_2e638229f7460b34ded7d5dec9f24ef6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-24T16:30:32Z"
+ content="""
+`etckeeper commit` adds any new files, and records any changes to file
+permissions or owners.
+"""]]

git request-pull -> +1 patch
diff --git a/doc/todo/Use_portable_command_-v.mdwn b/doc/todo/Use_portable_command_-v.mdwn
new file mode 100644
index 0000000..31f1dc5
--- /dev/null
+++ b/doc/todo/Use_portable_command_-v.mdwn
@@ -0,0 +1,26 @@
+```
+The following changes since commit 1b418610133e6de2b091ddf148df2846d535d5e8:
+
+  some issues with systemd and autocommit (2020-04-17 21:19:29 +0000)
+
+are available in the Git repository at:
+
+  https://github.com/eli-schwartz/etckeeper 
+
+for you to fetch changes up to d3f820b12d6dad3f59790780fbfcee0f30e6b11a:
+
+  Use portable "command -v" to detect installed programs (2020-04-19 04:27:59 -0400)
+
+----------------------------------------------------------------
+Eli Schwartz (1):
+      Use portable "command -v" to detect installed programs
+
+ debian/postinst                 | 2 +-
+ etckeeper                       | 2 +-
+ init.d/10restore-metadata       | 2 +-
+ pre-commit.d/30store-metadata   | 2 +-
+ uninit.d/50vcs-uninit           | 4 ++--
+ update-ignore.d/01update-ignore | 4 ++--
+ vcs.d/50vcs-cmd                 | 2 +-
+ 7 files changed, 9 insertions(+), 9 deletions(-)
+```

some issues with systemd and autocommit
diff --git a/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd.mdwn b/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd.mdwn
new file mode 100644
index 0000000..71229bf
--- /dev/null
+++ b/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd.mdwn
@@ -0,0 +1,10 @@
+there are two bugs in the Debian BTS that should probably be upstreamed here. I'm bundling them together because they are related, but it's true they are two distinct issues.
+
+ * [Please don't start both cron job and systemd.timer](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883263)
+ * [daily autocommit is run even though AVOID_DAILY_AUTOCOMMITS=1](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884824)
+
+I bundle them because they somewhat depend on each other. Could you review those patches and see if they are appropriate?
+
+They at least look good to me and I'm considering inclusion in the next upload...
+
+Let me know! -- [[anarcat]], your faithful debian packager...

diff --git a/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__.mdwn b/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__.mdwn
new file mode 100644
index 0000000..1f9923d
--- /dev/null
+++ b/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__.mdwn
@@ -0,0 +1,3 @@
+In the readme documentation for etckeeper, after the initial `etckeeper init` all commands are run using git (eg `git commit` or `git status`). Before finding the readme, I read several tutorials, DigitalOcean has one, that uses etckeeper instead (eg `etckeeper commit` or `etckeeper vcs status`). Do these pretty much do the same thing or should one be used over the other?
+
+Thanks!

remove post someone edited into the forum page itself
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
index d743987..af5229b 100644
--- a/doc/forum.mdwn
+++ b/doc/forum.mdwn
@@ -2,66 +2,3 @@ This is a place to discuss using etckeeper, share tips and tricks, etc.
 If you need help, advice, or anything, post about it here.
 
 [[!inline pages="forum/* and !*/Discussion" archive=yes rootpage=forum postformtext="Add a new thread titled:"]]
-
-I get this warning:
-
-etckeeper warning: hardlinked files could cause problems with git:
-PackageKit/events/post-transaction.d/README
-PackageKit/events/pre-transaction.d/README
-
-What kind of problems can happen?
-
-In my use case it is no problem if the hardlink gets lost and two individual files
-are in the repo.
-
-
-
-
-
-
-
-
-
------------------------------
-
-Thomas Güttler Nov 2018
-
-
-
- use etckeeper to track changes in /etc.
-
-Up to now the output of git log looks like this:
-
-commit c2364fd9a8465b07a1c31fafeb9ff4e4323770fe
-Author: Etckeeper running on foo-host <root@foo-host>
-Date:   Fri Aug 10 00:00:08 2018 +0200
-
-    daily
-
-commit d7b685f5f1a01b3f80b86202d6c461dac13b40ac
-Author: Etckeeper running on foo-host <root@foo-host>
-Date:   Wed Aug 8 00:00:07 2018 +0200
-
-    daily
-
-commit dd44e35ecdb27edad37763e88334fc659fd22ff1
-Author: Etckeeper running on foo-host <root@foo-host>
-Date:   Tue Aug 7 00:00:04 2018 +0200
-
-    daily
-
-commit f6b090e82c6d518be21c8b91f3f7999fbe1330db
-Author: Etckeeper running on foo-host <root@foo-host>
-Date:   Tue Jul 24 00:00:08 2018 +0200
-
-    daily
-
-....
-
-I would like to see which files have changed.
-
-Is there a way to get the list of changed files into the commit message of etckeeper?
-
-In most cases only one to three files change.
-
-If more than three files change, then it is enough to show the number of changed files.

add news item for etckeeper 1.18.14
diff --git a/doc/news/version_1.18.14.mdwn b/doc/news/version_1.18.14.mdwn
new file mode 100644
index 0000000..72862fe
--- /dev/null
+++ b/doc/news/version_1.18.14.mdwn
@@ -0,0 +1,6 @@
+etckeeper 1.18.14 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * pacman 5.2 deprecated File hooks, use Path.
+     Thanks, Christian Hesse
+   * Fix vcs subcommand setup for zsh completion.
+     Thanks, James Rowe."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.9.mdwn b/doc/news/version_1.18.9.mdwn
deleted file mode 100644
index 5ef251b..0000000
--- a/doc/news/version_1.18.9.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-etckeeper 1.18.9 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * When run during a package installation, include in the commit
-     message the command line that caused etckeeper to run.
-     Thanks, Laszlo Gombos"""]]
\ No newline at end of file

comment
diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_6_0e06add692d4dc5cd61ba037159669be._comment b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_6_0e06add692d4dc5cd61ba037159669be._comment
new file mode 100644
index 0000000..4719957
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_6_0e06add692d4dc5cd61ba037159669be._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-01-21T19:23:41Z"
+ content="""
+dnf2 sinks etckeeper's stdout and stderr to /dev/null
+
+`etckeeper pre-install`, when `AVOID_COMMIT_BEFORE_INSTALL` is set,
+outputs an error to stderr, and exits nonzero. The expectation is
+that the package installation is canceled. (I don't know if that happens
+with etckeeper-dnf; it kind of looks like it warns and continues?)
+
+If etckeeper pre-install exiting nonzero does prevent the upgrade from
+happening, and the message about it goes to /dev/null, that seems like a
+surprising situation for the user to be confronted with.
+"""]]

comment
diff --git a/doc/todo/Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS/comment_1_3cafcd2709f32dfe583dc42933f542cb._comment b/doc/todo/Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS/comment_1_3cafcd2709f32dfe583dc42933f542cb._comment
new file mode 100644
index 0000000..6e24336
--- /dev/null
+++ b/doc/todo/Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS/comment_1_3cafcd2709f32dfe583dc42933f542cb._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-21T19:00:14Z"
+ content="""
+I'm not thrilled by this idea. It's not uncommon for etckeeper.conf to be
+packaged by a distribution. Upgrading the package may replace the
+local etckeeper.conf (takes only answering "Y" on debian). If that changes
+out the VCS setting, then etckeeper suddently stops using the repository it
+was using.
+
+The README documents how to change the VCS that etckeeper uses. So I think
+it would be better to document that VCS setting in etckeeper.conf only
+applies to `etckeeper init`. Or alternatively, to add a parameter like
+`etckeeper init --vcs=git`.
+
+It's true that neither of those options would cater to a system that has
+two different version control repositories checked out in /etc at the same
+time, but that sounds like a sufficiently strange/bad idea that I see no
+reason to cater to it.
+"""]]

Question on hooks during rebase
diff --git a/doc/forum/Prevent_hook_running_during_rebase.mdwn b/doc/forum/Prevent_hook_running_during_rebase.mdwn
new file mode 100644
index 0000000..7ba631a
--- /dev/null
+++ b/doc/forum/Prevent_hook_running_during_rebase.mdwn
@@ -0,0 +1,24 @@
+Normally, when I wish to fix or clean up history I’ll do The Right Thing(clone
+`/etc` repo, edit, and force `pull` the changes).  *However*, occasionally I’ll
+perform a quick in-place `rebase` when the depth is *very* shallow or will be
+non-destructive.
+
+If — like me — you do this then you’ve probably been bitten by `.etckeeper`
+breakage when simply re-ordering commits.  If so, then the following addition to
+your `.git/hooks/pre-commit` will prevent the hook running while in a `rebase`
+session.
+
+```
+if git branch | grep -q '^\* (no branch'; then
+    echo "Skipping pre-commit hook in rebase" >&2
+    exit 0
+fi
+```
+
+**Note**: The unbalanced parenthesis in the match is on purpose, depending on
+your `git` version you could have a simple `(no branch)` or the far more helpful
+`(no branch, rebasing <branch>)` branch name.
+
+I’d be interested to know if other users have a better way to handle this.
+
+-- James

Format my previous edit as a comment
diff --git a/doc/forum/etckeeper_wants_root_git_identity.mdwn b/doc/forum/etckeeper_wants_root_git_identity.mdwn
index 8f50b84..4baec38 100644
--- a/doc/forum/etckeeper_wants_root_git_identity.mdwn
+++ b/doc/forum/etckeeper_wants_root_git_identity.mdwn
@@ -2,7 +2,14 @@ I've installed etckeeper & git on a new machine running arch.  I've got sudo and
 
 ---
 
+[[!comment  format=mdwn
+username="https://peterjmello.wordpress.com/"
+nickname="RogueScholar"
+date="2020-01-10T19:22:30-0800"
+content="""
 One possible solution to your issue would be to edit `/etc/etckeeper/etckeeper.conf` and change the VCS variable value to include the location of your gitconfig file. Assuming yours is in the default location of `~/.gitconfig` that would mean changing it from `VCS="git"` to `VCS="git -f /home/<yourusername>/.gitconfig"` (be sure to use the canonical path to the file rather than relying on the `~` alias for your home directory because in this instance ~ points to `/root`).
 
 -Peter
->[[!fortune  ]]
+"""
+]]
+>[[!fortune ]]

Offer possible solution
diff --git a/doc/forum/etckeeper_wants_root_git_identity.mdwn b/doc/forum/etckeeper_wants_root_git_identity.mdwn
index 90a4ffb..8f50b84 100644
--- a/doc/forum/etckeeper_wants_root_git_identity.mdwn
+++ b/doc/forum/etckeeper_wants_root_git_identity.mdwn
@@ -1 +1,8 @@
 I've installed etckeeper & git on a new machine running arch.  I've got sudo and git setup for my regular user.  When I `sudo etckeeper commit "Initial commit"` git gives me the usual message about empty ident name for root@host.  Documentation suggests that sudo will grab the ident of sudo user but that doesn't seem to be working.  I'm running etckeeper 1.18.12-1.  What am I missing?
+
+---
+
+One possible solution to your issue would be to edit `/etc/etckeeper/etckeeper.conf` and change the VCS variable value to include the location of your gitconfig file. Assuming yours is in the default location of `~/.gitconfig` that would mean changing it from `VCS="git"` to `VCS="git -f /home/<yourusername>/.gitconfig"` (be sure to use the canonical path to the file rather than relying on the `~` alias for your home directory because in this instance ~ points to `/root`).
+
+-Peter
+>[[!fortune  ]]

response
diff --git a/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__/comment_1_a14869bdf298370a0b307c352759ee80._comment b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__/comment_1_a14869bdf298370a0b307c352759ee80._comment
new file mode 100644
index 0000000..8294778
--- /dev/null
+++ b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__/comment_1_a14869bdf298370a0b307c352759ee80._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-12-25T19:44:29Z"
+ content="""
+An admin might expect to be able to `mv passwd- passwd` to undo the most
+recent change, and if so that might as well be supported after restoring
+/etc from backup.
+
+There is essentially no overhead in adding these files since they have the
+same content as an older commit of the passwd file.
+"""]]

add news item for etckeeper 1.18.13
diff --git a/doc/news/version_1.18.13.mdwn b/doc/news/version_1.18.13.mdwn
new file mode 100644
index 0000000..fe8d5a8
--- /dev/null
+++ b/doc/news/version_1.18.13.mdwn
@@ -0,0 +1,6 @@
+etckeeper 1.18.13 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Added zsh completion.
+     Thanks, James Rowe
+   * commit: Recent changes added code that does not work on all POSIX shells.
+     Fixed by Thorsten Glaser."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.8.mdwn b/doc/news/version_1.18.8.mdwn
deleted file mode 100644
index 3f1353c..0000000
--- a/doc/news/version_1.18.8.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-etckeeper 1.18.8 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Work around git commit's lack of robustness, by providing
-     reasonable default values for GIT\_COMMITTER\_EMAIL etc.
-     This was already done as part of the su/sudo handling,
-     and is now always done.
-   * Don't hardcode the master branch when pushing to PUSH\_REMOTE.
-     Instead, let git push whatever branches it is configured to
-     push to that remote."""]]
\ No newline at end of file

fix portability breakage
commit: Recent changes added code that does not work on all POSIX shells.
Fixed by Thorsten Glaser.
diff --git a/commit.d/50vcs-commit b/commit.d/50vcs-commit
index 4eaeb26..bd4b1d4 100755
--- a/commit.d/50vcs-commit
+++ b/commit.d/50vcs-commit
@@ -12,10 +12,9 @@ if [ -n "$1" ]; then
 	if [ "x$1" = "x--stdin" ]; then
 		cat > "$logfile"
 	else
-		if [ "x$1" = "x-m" ]; then
-			shift 1
-		fi
-		echo "${@#-m}" > "$logfile"
+		sed '1s/^-m \{0,1\}//' >"$logfile" <<-EOF
+			$*
+		EOF
 	fi
 else
 	logfile=""
diff --git a/debian/changelog b/debian/changelog
index db18129..d8a3751 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ etckeeper (1.18.13) UNRELEASED; urgency=medium
 
   * Added zsh completion.
     Thanks, James Rowe
+  * commit: Recent changes added code that does not work on all POSIX shells.
+    Fixed by Thorsten Glaser.
 
  -- Joey Hess <id@joeyh.name>  Fri, 13 Dec 2019 09:17:48 -0500
 
diff --git a/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn b/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn
index ccd4b40..8a2d78e 100644
--- a/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn
+++ b/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn
@@ -29,3 +29,5 @@ The bug suggests a patch that uses `sed` instead of that pattern substitution:
      	logfile=""
 
 Thanks! -- [[anarcat]]
+
+> [[done]] --[[Joey]]

forward debian bug #946055
diff --git a/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn b/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn
new file mode 100644
index 0000000..ccd4b40
--- /dev/null
+++ b/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn
@@ -0,0 +1,31 @@
+[Bug #946055](https://bugs.debian.org/946055) mentions that if `/bin/sh` is not bash, it will fail (specifically with mksh):
+
+>     /etc/etckeeper/commit.d/50vcs-commit[22]: ${@#-m}: bad substitution
+> 
+> This is because doing trim operations on an array are not implemented
+> in mksh, and unspecified in POSIX:
+> 
+> […] If parameter is '#', '*', or '@', the result of the expansion is unspecified. […]
+> 
+> cf. <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02>
+
+The bug suggests a patch that uses `sed` instead of that pattern substitution:
+
+    --- a/commit.d/50vcs-commit
+    +++ b/commit.d/50vcs-commit
+    @@ -12,10 +12,9 @@ if [ -n "$1" ]; then
+     	if [ "x$1" = "x--stdin" ]; then
+     		cat > "$logfile"
+     	else
+    -		if [ "x$1" = "x-m" ]; then
+    -			shift 1
+    -		fi
+    -		echo "${@#-m}" > "$logfile"
+    +		sed '1s/^-m \{0,1\}//' >"$logfile" <<-EOF
+    +			$*
+    +		EOF
+     	fi
+     else
+     	logfile=""
+
+Thanks! -- [[anarcat]]

diff --git a/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
index 4f5af90..f1a47fe 100644
--- a/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
+++ b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
@@ -10,4 +10,4 @@ From https://git.joeyh.name/index.cgi/etckeeper.git/tree/update-ignore.d/01updat
 
 > \#ignore "gshadow-"
 
-But I can't understand the reason, considering that ignoring these backup files justs leaves them there so admins can still use them. In the other hand, having the original files (e.g. `passwd`) under version control will provide the expected history of changes.
+But I can't understand the reason, considering that ignoring these backup files justs leaves them there so admins can still use them. In the other hand, having the original files (e.g. `passwd`) under version control will provide admins the expected history of changes.

diff --git a/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
index 191a6a5..4f5af90 100644
--- a/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
+++ b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
@@ -1,9 +1,13 @@
 From https://git.joeyh.name/index.cgi/etckeeper.git/tree/update-ignore.d/01update-ignore#n110:
 
-> # Not currently ignored as admins tend to rely on these files.
-> #ignore "passwd-"
-> #ignore "group-"
-> #ignore "shadow-"
-> #ignore "gshadow-"
+> \# Not currently ignored as admins tend to rely on these files.
+
+> \#ignore "passwd-"
+
+> \#ignore "group-"
+
+> \#ignore "shadow-"
+
+> \#ignore "gshadow-"
 
 But I can't understand the reason, considering that ignoring these backup files justs leaves them there so admins can still use them. In the other hand, having the original files (e.g. `passwd`) under version control will provide the expected history of changes.

diff --git a/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
new file mode 100644
index 0000000..191a6a5
--- /dev/null
+++ b/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn
@@ -0,0 +1,9 @@
+From https://git.joeyh.name/index.cgi/etckeeper.git/tree/update-ignore.d/01update-ignore#n110:
+
+> # Not currently ignored as admins tend to rely on these files.
+> #ignore "passwd-"
+> #ignore "group-"
+> #ignore "shadow-"
+> #ignore "gshadow-"
+
+But I can't understand the reason, considering that ignoring these backup files justs leaves them there so admins can still use them. In the other hand, having the original files (e.g. `passwd`) under version control will provide the expected history of changes.

diff --git a/doc/forum/etckeeper_wants_root_git_identity.mdwn b/doc/forum/etckeeper_wants_root_git_identity.mdwn
new file mode 100644
index 0000000..90a4ffb
--- /dev/null
+++ b/doc/forum/etckeeper_wants_root_git_identity.mdwn
@@ -0,0 +1 @@
+I've installed etckeeper & git on a new machine running arch.  I've got sudo and git setup for my regular user.  When I `sudo etckeeper commit "Initial commit"` git gives me the usual message about empty ident name for root@host.  Documentation suggests that sudo will grab the ident of sudo user but that doesn't seem to be working.  I'm running etckeeper 1.18.12-1.  What am I missing?

add news item for etckeeper 1.18.12
diff --git a/doc/news/version_1.18.12.mdwn b/doc/news/version_1.18.12.mdwn
new file mode 100644
index 0000000..c02b04f
--- /dev/null
+++ b/doc/news/version_1.18.12.mdwn
@@ -0,0 +1,4 @@
+etckeeper 1.18.12 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix bug in hostname determination in the previous release.
+     Thanks, Christian Hesse"""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.7.mdwn b/doc/news/version_1.18.7.mdwn
deleted file mode 100644
index 8259825..0000000
--- a/doc/news/version_1.18.7.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-etckeeper 1.18.7 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Added some unit tests.
-     Thanks, Henrik Riomar.
-   * etckeeper will work on systems that do not have perl installed.
-     (perl is still used when available as it's faster)
-     Thanks, William Johansson and radhus.
-   * Prevent LC\_ALL overriding the LC\_COLLATE used to sort metadata."""]]
\ No newline at end of file

add news item for etckeeper 1.18.11
diff --git a/doc/news/version_1.18.11.mdwn b/doc/news/version_1.18.11.mdwn
new file mode 100644
index 0000000..85ef585
--- /dev/null
+++ b/doc/news/version_1.18.11.mdwn
@@ -0,0 +1,12 @@
+etckeeper 1.18.11 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Support platforms without a hostname command, fall back to
+     reading /etc/hostname.
+     Thanks, Chris Morgan
+   * commit: Support -mmessage, without a space, since eg git commit
+     can be used that way.
+     Thanks, martin f. krafft
+   * commit: When multiple parameters are given, use them all as the commit
+     message, instead of the old behavior of only using the first parameter and
+     throwing the rest away.
+     Thanks, martin f. krafft"""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.6.mdwn b/doc/news/version_1.18.6.mdwn
deleted file mode 100644
index c83b9da..0000000
--- a/doc/news/version_1.18.6.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-etckeeper 1.18.6 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Only show errors (no progress indicators) when pushing Git/Mercurial repos
-     to avoid unncessary cron mails.
-     Thanks, Nils Steinger.
-   * Fix regex in 20-warn-problem-files.
-   * Added support for apk (alpine linux)
-     Thanks, Henrik Riomar."""]]
\ No newline at end of file

Added a comment: How about "etckeeper > /dev/null" ?
diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_5_b117c5f77ebb26d26634248f68ee3e1a._comment b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_5_b117c5f77ebb26d26634248f68ee3e1a._comment
new file mode 100644
index 0000000..94281c1
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_5_b117c5f77ebb26d26634248f68ee3e1a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="alan.christopher.jenkins@a53b5c6056bc7d7b09e181c23cc2ec8362fa7abe"
+ nickname="alan.christopher.jenkins"
+ avatar="http://cdn.libravatar.org/avatar/599d943d715a521e4c23ab2a46ac70dc"
+ subject="How about &quot;etckeeper > /dev/null&quot; ?"
+ date="2019-10-28T17:08:20Z"
+ content="""
+See same github repo, branch \"dnf2\", commit 7cda9678b1e60c0495a2a522721b319843d5fae0
+
+Sorry for the delay. I can't find a record of an email notification.
+
+In response to Joey's comment, I've tried sending all the etckeeper output to /dev/null.  I find the resulting code more friendly to read, because it avoids my very long code comment :).
+
+I interpreted \"in this case\" as just meaning \"in etckeeper-dnf\".  I think you could technically check whether you are dnf v.s. a different libdnf client like Ansible, but I didn't want to :).
+
+syslog.syslog() did not seem very helpful.  In python2 it appears to encode unicode using ascii, regardless of the locale.  I think we might be able to drop support for python2-dnf.  But still, the system log seems a bit unexpected, compared to stderr, /var/log/dnf.plugin.log, /var/log/dnf.log, or whatever custom logger the host program set up.
+"""]]

response
diff --git a/doc/forum/Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_/comment_1_431b3e7e1887d897335f35b1bfaf0351._comment b/doc/forum/Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_/comment_1_431b3e7e1887d897335f35b1bfaf0351._comment
new file mode 100644
index 0000000..ba5ca62
--- /dev/null
+++ b/doc/forum/Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_/comment_1_431b3e7e1887d897335f35b1bfaf0351._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-08-08T15:25:59Z"
+ content="""
+Whether that is possible depends on what hooks, if any,
+snapd supports.
+
+etckeeper's todo list is here: [[todo]]
+"""]]

diff --git a/doc/forum/Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_.mdwn b/doc/forum/Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_.mdwn
new file mode 100644
index 0000000..38d53f5
--- /dev/null
+++ b/doc/forum/Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_.mdwn
@@ -0,0 +1,9 @@
+I like that etckeeper can block my attempt at apt-get installing anything when there are pending changes in /etc
+
+
+Can this also be done with stuff installed from the Snap Store (https://snapcraft.io/store)?
+
+
+I've been looking for the git repository for this project to look for an issue tracker, but couldn't find anything 'official'.
+
+Cheers

Added a comment: Reference to the corresponding bug analysis in Ansible
diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_3_1dcb2bdbc7ae9fc8746e75d9ce8305ff._comment b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_3_1dcb2bdbc7ae9fc8746e75d9ce8305ff._comment
new file mode 100644
index 0000000..80b2616
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_3_1dcb2bdbc7ae9fc8746e75d9ce8305ff._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="webknjaz@282aadd575f8161e52a787ad51e8ba046b8289a9"
+ nickname="webknjaz"
+ avatar="http://cdn.libravatar.org/avatar/6268a71f6afd8dc3875df5624f8bf85c"
+ subject="Reference to the corresponding bug analysis in Ansible "
+ date="2019-06-06T20:16:40Z"
+ content="""
+Hi,
+
+I've been tracking down this issue on the Ansible side and just wanted to share [this comment on GitHub](https://github.com/ansible/ansible/issues/54949#issuecomment-499541669).
+
+Any estimations on when this gets applied upstream?
+"""]]

followup
diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_2_81c341d479a56a2fa79c9c519a130ef3._comment b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_2_81c341d479a56a2fa79c9c519a130ef3._comment
new file mode 100644
index 0000000..8b03a27
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_2_81c341d479a56a2fa79c9c519a130ef3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-04-23T23:09:47Z"
+ content="""
+Given the difficulty in feeding etckeeper output through this, would it
+perhaps be better to do something else with its output in this case, either
+/dev/nulling it or writing it to the syslog or something like that?
+"""]]

Added a comment: Have a bonus commit: 3d431ea67922 "Do not use dnfpluginscore.logger"
diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_2_ff2b6e899a2f363b623aa1eff6c0adcc._comment b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_2_ff2b6e899a2f363b623aa1eff6c0adcc._comment
new file mode 100644
index 0000000..a9b2f3b
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_2_ff2b6e899a2f363b623aa1eff6c0adcc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="sourcejedi"
+ avatar="http://cdn.libravatar.org/avatar/599d943d715a521e4c23ab2a46ac70dc"
+ subject="Have a bonus commit: 3d431ea67922 &quot;Do not use dnfpluginscore.logger&quot;"
+ date="2019-04-23T19:17:50Z"
+ content="""
+dnfpluginscore is not core support for dnf plugins, it is just a
+collection of \"core plugins\" for dnf.  There is equally
+dnfpluginsextras and dnfpluginsextras.logger.
+
+A comment in dnf.logger comment says the logger name 'dnf.plugin' is \"api\".
+So we can safely rely on that name.
+
+Technically you can install etckeeper without the dnfpluginscore package
+(at least I managed to run into this for python2, on a Fedora 29 system
+which uses python3 for dnf by default).
+"""]]

Added a comment: Oops. Revised version
diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_1_add80827135b358d3b55565e2168af00._comment b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_1_add80827135b358d3b55565e2168af00._comment
new file mode 100644
index 0000000..32fd770
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_1_add80827135b358d3b55565e2168af00._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="sourcejedi"
+ avatar="http://cdn.libravatar.org/avatar/599d943d715a521e4c23ab2a46ac70dc"
+ subject="Oops. Revised version"
+ date="2019-04-19T14:38:57Z"
+ content="""
+Please find a revised commit in the dnf branch of https://github.com/sourcejedi/etckeeper.git
+
+commit id: afbdce2d24b46bc91840044b953aca8b68f20fd3
+
+(The previous commit was not as safe as I thought.
+
+If the etckeeper output includes an un-decodable byte, we would convert it to a unicode string which contains U+FFFD.  This codepoint is *not* available in all character encodings, so it can cause UnicodeEncodeError.  It's not fatal in current versions of dnf, because they set logging.RaiseExceptions = false.  However it could lose an entire line of output.)
+"""]]

diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible.mdwn b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible.mdwn
new file mode 100644
index 0000000..2a41cdf
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible.mdwn
@@ -0,0 +1,18 @@
+The following changes since commit c88551e939ed9349e7cc9be3e384749633b79655:
+
+  I am in awe of /etc/etckeeper/*.d/ (2019-03-18 14:36:14 +0000)
+
+are available in the Git repository at:
+
+  https://github.com/sourcejedi/etckeeper.git 
+
+for you to fetch changes up to 040f5b2cb808ad9791d2c6f2f916fd887d2e16fa:
+
+  DNF: fix logging, now it will work from Ansible (2019-04-13 18:21:47 +0100)
+
+----------------------------------------------------------------
+Alan Jenkins (1):
+      DNF: fix logging, now it will work from Ansible
+
+ etckeeper-dnf/etckeeper.py | 48 ++++++++++++++++++++++++++++++++++++++++++------
+ 1 file changed, 42 insertions(+), 6 deletions(-)

I am in awe of /etc/etckeeper/*.d/
diff --git a/doc/forum/Joey_you_just_blew_my_mind..mdwn b/doc/forum/Joey_you_just_blew_my_mind..mdwn
new file mode 100644
index 0000000..93a4179
--- /dev/null
+++ b/doc/forum/Joey_you_just_blew_my_mind..mdwn
@@ -0,0 +1,10 @@
+While trying to add etckeeper to some other system today, I ran:
+
+    $ etckeeper help
+    etckeeper: /etc/etckeeper/help.d does not exist
+
+And now I'm wondering why I don't just make *all* of my big scripts call `run-parts` on the subcommands.
+
+# Why was I not informed sooner?
+
+Anyway thanks, Joey, I learned a cool new trick today!

Added a comment: Also relevant to Entware
diff --git a/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_3_3d3af5448206218df3f29a2ff4d8b92e._comment b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_3_3d3af5448206218df3f29a2ff4d8b92e._comment
new file mode 100644
index 0000000..069614a
--- /dev/null
+++ b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_3_3d3af5448206218df3f29a2ff4d8b92e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://peterjmello.wordpress.com/"
+ nickname="RogueScholar"
+ avatar="http://cdn.libravatar.org/avatar/2d57e52a1ae78a222266afb46fe3c1c4"
+ subject="Also relevant to Entware"
+ date="2019-01-04T10:26:46Z"
+ content="""
+I was just thinking that it would be nice to have etckeeper operating on my home networking gear similar to how I use it on my PCs. Since they all run either OpenWRT or Tomato/Merlin, a package that interfaced with the opkg management system would be ideal. Specifically it's the fact that the directory it would need to monitor would be /opt/etc and not /etc that I'm not quite sure how to go about implementing.
+
+Has there been any movement on this process? I'd be happy to put my shoulder to the wheel on it if someone with more familiarity with the codebase could describe the tasks involved. Failing that I'd be happy to test anyone else's attempts. Huge fan of the project, thanks so much for all the work that's been put in on it to date.
+"""]]

add news item for etckeeper 1.18.10
diff --git a/doc/news/version_1.18.10.mdwn b/doc/news/version_1.18.10.mdwn
new file mode 100644
index 0000000..e949498
--- /dev/null
+++ b/doc/news/version_1.18.10.mdwn
@@ -0,0 +1,5 @@
+etckeeper 1.18.10 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Avoid post-install failing when ps is from busybox or another
+     version not supporting procps-specific options.
+   * Use ps --no-headers rather than problimatic -h option."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.5.mdwn b/doc/news/version_1.18.5.mdwn
deleted file mode 100644
index 0d44e7b..0000000
--- a/doc/news/version_1.18.5.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-etckeeper 1.18.5 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Make etckeeper commit store metadata changes. The pre-commit
-     hook has always (and continues) to do that, but pre-commit is only
-     run when there are changes to tommit. This makes metadata-only
-     changes get committed.
-   * Move systemd files to /lib/systemd; /usr/lib/systemd is not used
-     on Debian."""]]
\ No newline at end of file

ps is so nonstandard
* Avoid post-install failing when ps is from busybox or another
version not supporting procps-specific options.
* Use ps --no-headers rather than problimatic -h option.
This commit was sponsored by Eric Drechsel on Patreon.
diff --git a/debian/changelog b/debian/changelog
index 8b15880..fcb7d6a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+etckeeper (1.18.10) UNRELEASED; urgency=medium
+
+  * Avoid post-install failing when ps is from busybox or another
+    version not supporting procps-specific options.
+  * Use ps --no-headers rather than problimatic -h option.
+
+ -- Joey Hess <id@joeyh.name>  Sun, 23 Dec 2018 13:01:28 -0400
+
 etckeeper (1.18.9) unstable; urgency=medium
 
   * When run during a package installation, include in the commit
diff --git a/doc/forum/1.18.9_broken_with_busybox_ps/comment_2_b89bc67dd20946798691372635ba91b0._comment b/doc/forum/1.18.9_broken_with_busybox_ps/comment_2_b89bc67dd20946798691372635ba91b0._comment
new file mode 100644
index 0000000..76679e3
--- /dev/null
+++ b/doc/forum/1.18.9_broken_with_busybox_ps/comment_2_b89bc67dd20946798691372635ba91b0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-12-23T17:05:17Z"
+ content="""
+Fixed.
+
+(Ps, please use the todo page not the forum for reporting problems.)
+"""]]
diff --git a/post-install.d/50vcs-commit b/post-install.d/50vcs-commit
index d494968..bc9cdf0 100755
--- a/post-install.d/50vcs-commit
+++ b/post-install.d/50vcs-commit
@@ -4,12 +4,14 @@ set -e
 pl="/var/cache/etckeeper/packagelist"
 
 # Parent process is etckeeper
-ETCKEEPER_PID=$( ps -ho ppid "${PPID}" | sed 's/^ *//' )
+# (Only procps ps is currently supported, others will fail,
+# so this may end up empty.)
+ETCKEEPER_PID=$( ps --no-headers -o ppid "${PPID}" 2>/dev/null | sed 's/^ *//' )
 
 # Find the parent of etckeeper and get the command line of the process
 if ! [ -z "${ETCKEEPER_PID}" ]; then
-	ETCKEEPER_PPID=$( ps -ho ppid "${ETCKEEPER_PID}" | sed 's/^ *//' )
-	ETCKEEPER_PARENT_COMMAND_LINE=$( ps -ho args "${ETCKEEPER_PPID}" )
+	ETCKEEPER_PPID=$( ps --no-headers -o ppid "${ETCKEEPER_PID}" | sed 's/^ *//' )
+	ETCKEEPER_PARENT_COMMAND_LINE=$( ps --no-headers -o args "${ETCKEEPER_PPID}" )
 fi
 
 if etckeeper unclean; then
@@ -37,5 +39,5 @@ if etckeeper unclean; then
 		echo "warning: etckeeper failed to commit changes in /etc using $VCS" >&2
 	fi
 fi
-	
+
 rm -f $pl.pre-install $pl.fmt

followup
diff --git a/doc/forum/1.18.9_broken_with_busybox_ps/comment_1_ee6109c7209febb6fbec0e99c3901672._comment b/doc/forum/1.18.9_broken_with_busybox_ps/comment_1_ee6109c7209febb6fbec0e99c3901672._comment
new file mode 100644
index 0000000..029bb95
--- /dev/null
+++ b/doc/forum/1.18.9_broken_with_busybox_ps/comment_1_ee6109c7209febb6fbec0e99c3901672._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-23T16:52:32Z"
+ content="""
+Another problem with busybox ps and that patch is that while `ps 1`
+normally shows only pid 1, `busybox ps 1` lists all pids.
+
+So it doesn't seem that code path can support busybox ps at all,
+and probably the safest thing to do is to use --no-headers to make procps's
+ps always do the right thing no matter how configured, and if that fails,
+/dev/null the error and fall back to not including the command line in
+the commit message.
+"""]]

diff --git a/doc/forum/1.18.9_broken_with_busybox_ps.mdwn b/doc/forum/1.18.9_broken_with_busybox_ps.mdwn
new file mode 100644
index 0000000..d176404
--- /dev/null
+++ b/doc/forum/1.18.9_broken_with_busybox_ps.mdwn
@@ -0,0 +1,29 @@
+Hi,
+
+The following commit:
+    
+    ec8d1ad Add the package manager or any other parent process command to the commit log
+
+breaks etckeeper on systems with Busybox ps:
+
+
+    ps: unrecognized option: h
+    BusyBox v1.29.3 (2018-11-21 11:45:56 UTC) multi-call binary.
+    
+    Usage: ps [-o COL1,COL2=HEADER]
+    
+    Show list of processes
+   
+           -o COL1,COL2=HEADER     Select columns for display
+
+
+From the Debian manpage on the `h` option:
+
+    h      No header.  (or, one header per screen in the BSD personality).  The h option is problematic.  Standard BSD ps uses this
+              option to print a header on each page of output, but older Linux ps uses this option to totally disable the header.  This
+              version of ps follows the Linux usage of not printing the header unless the BSD personality has been selected, in which case
+              it prints a header on each page of output.  Regardless of the current personality, you can use the long options --headers
+              and --no-headers to enable printing headers each page or disable headers entirely, respectively.
+
+
+So the use of `h` could affect the portability of `etckeeper` and the problem is not limited to Busybox `ps`.

add news item for etckeeper 1.18.9
diff --git a/doc/news/version_1.18.4.mdwn b/doc/news/version_1.18.4.mdwn
deleted file mode 100644
index 9b9bf0a..0000000
--- a/doc/news/version_1.18.4.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-etckeeper 1.18.4 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Optimised find for special and hard linked files.
-     Thanks, Rike-Benjamin Schuppner.
-   * Adjust when Pacman 5 calls etckeeper hooks.
-     Thanks, Tilman Blumenbach and Christian Hesse.
-   * Only run Pacman hooks when files in /etc have changed.
-     Thanks, Christian Hesse.
-   * Added systemd timer that can run etckeeper 10 minutes after boot, and also
-     daily. It's not enabled by default, partly because of overlap with the
-     cron job.
-     Thanks, Christian Hesse."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.9.mdwn b/doc/news/version_1.18.9.mdwn
new file mode 100644
index 0000000..5ef251b
--- /dev/null
+++ b/doc/news/version_1.18.9.mdwn
@@ -0,0 +1,5 @@
+etckeeper 1.18.9 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * When run during a package installation, include in the commit
+     message the command line that caused etckeeper to run.
+     Thanks, Laszlo Gombos"""]]
\ No newline at end of file

I want to see the list of changes files in the commit message.
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
index f64a9c6..d743987 100644
--- a/doc/forum.mdwn
+++ b/doc/forum.mdwn
@@ -13,3 +13,55 @@ What kind of problems can happen?
 
 In my use case it is no problem if the hardlink gets lost and two individual files
 are in the repo.
+
+
+
+
+
+
+
+
+
+-----------------------------
+
+Thomas Güttler Nov 2018
+
+
+
+ use etckeeper to track changes in /etc.
+
+Up to now the output of git log looks like this:
+
+commit c2364fd9a8465b07a1c31fafeb9ff4e4323770fe
+Author: Etckeeper running on foo-host <root@foo-host>
+Date:   Fri Aug 10 00:00:08 2018 +0200
+
+    daily
+
+commit d7b685f5f1a01b3f80b86202d6c461dac13b40ac
+Author: Etckeeper running on foo-host <root@foo-host>
+Date:   Wed Aug 8 00:00:07 2018 +0200
+
+    daily
+
+commit dd44e35ecdb27edad37763e88334fc659fd22ff1
+Author: Etckeeper running on foo-host <root@foo-host>
+Date:   Tue Aug 7 00:00:04 2018 +0200
+
+    daily
+
+commit f6b090e82c6d518be21c8b91f3f7999fbe1330db
+Author: Etckeeper running on foo-host <root@foo-host>
+Date:   Tue Jul 24 00:00:08 2018 +0200
+
+    daily
+
+....
+
+I would like to see which files have changed.
+
+Is there a way to get the list of changed files into the commit message of etckeeper?
+
+In most cases only one to three files change.
+
+If more than three files change, then it is enough to show the number of changed files.

diff --git a/doc/forum/Make_pre-commit.d__47__30store-metadata:generate__95__metadata__40____41___filter_Git_sub_modules.mdwn b/doc/forum/Make_pre-commit.d__47__30store-metadata:generate__95__metadata__40____41___filter_Git_sub_modules.mdwn
new file mode 100644
index 0000000..0fd902c
--- /dev/null
+++ b/doc/forum/Make_pre-commit.d__47__30store-metadata:generate__95__metadata__40____41___filter_Git_sub_modules.mdwn
@@ -0,0 +1,8 @@
+It would be great if the function generate_metadata() in pre-commit.d/30store-metadata would not only filter ignore patterns from .gitignore, but if it would also filter any files inside Git sub modules.
+
+Information about Git sub modules is being stored in a .gitmodules files, similar to this (example):
+```
+[submodule "path/to/dir"]
+        path = path/to/dir
+        url = https://...
+```

add news item for etckeeper 1.18.8
diff --git a/doc/news/version_1.18.3.mdwn b/doc/news/version_1.18.3.mdwn
deleted file mode 100644
index e713eae..0000000
--- a/doc/news/version_1.18.3.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-etckeeper 1.18.3 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Added support for pacmatic, contributed by nicolaichuk.
-   * bzr: make sure EMAIL is defined
-     Thanks, Serge E. Hallyn
-   * Fix Makefile version patterns to ignore non-native version number
-     (Antoine Beaupré)
-   * Support ~/.config/git/config when determining the author name and email.
-     Thanks, Richard Savio
-   * Added support for Arch's pacman package manager version 5.
-     Thanks, Tilman Blumenbach.
-   * Set HOME if it's not set, as is the case when using ubuntu's
-     update-manager.
-   * Move bash completion out of etc and into usr."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.8.mdwn b/doc/news/version_1.18.8.mdwn
new file mode 100644
index 0000000..3f1353c
--- /dev/null
+++ b/doc/news/version_1.18.8.mdwn
@@ -0,0 +1,9 @@
+etckeeper 1.18.8 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Work around git commit's lack of robustness, by providing
+     reasonable default values for GIT\_COMMITTER\_EMAIL etc.
+     This was already done as part of the su/sudo handling,
+     and is now always done.
+   * Don't hardcode the master branch when pushing to PUSH\_REMOTE.
+     Instead, let git push whatever branches it is configured to
+     push to that remote."""]]
\ No newline at end of file

Don't hardcode the master branch when pushing to PUSH_REMOTE.
Instead, let git push whatever branches it is configured to push to that
remote.
This allows for branches other than master to be checked out and be pushed.
git has several configs for what branches to push, including
push.default, and remote.*.push.
This commit was sponsored by Trenton Cronholm on Patreon.
diff --git a/commit.d/99push b/commit.d/99push
index b5418f7..3df1350 100755
--- a/commit.d/99push
+++ b/commit.d/99push
@@ -2,7 +2,7 @@
 if [ -n "$PUSH_REMOTE" ]; then
 	if [ "$VCS" = git ] && [ -d .git ]; then
 		for REMOTE in $PUSH_REMOTE; do
-			git push "$REMOTE" master || true
+			git push "$REMOTE" || true
 		done
 	elif [ "$VCS" = hg ] && [ -d .hg ]; then
 		for REMOTE in $PUSH_REMOTE; do
diff --git a/debian/changelog b/debian/changelog
index 46df223..fcc170a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,9 @@ etckeeper (1.18.8) UNRELEASED; urgency=medium
     reasonable default values for GIT_COMMITTER_EMAIL etc.
     This was already done as part of the su/sudo handling,
     and is now always done.
+  * Don't hardcode the master branch when pushing to PUSH_REMOTE.
+    Instead, let git push whatever branches it is configured to
+    push to that remote.
 
  -- Joey Hess <id@joeyh.name>  Thu, 08 Jun 2017 13:22:01 -0400
 
diff --git a/doc/todo/push_remote_branch.mdwn b/doc/todo/push_remote_branch.mdwn
index 17cb514..67f156e 100644
--- a/doc/todo/push_remote_branch.mdwn
+++ b/doc/todo/push_remote_branch.mdwn
@@ -10,3 +10,7 @@ remove it, and add to the readme an example of writing your own
 `/etc/etckeeper/commit.d/99push` script that does exactly the kind of
 pushing you want. The only reason I've not done so is it would break
 compatibility for anyone using this feature. --[[Joey]]
+
+> Well, there was no point in it hardcoding master. `git push origin` will
+> push whatever branches you've configured git to push. So, made that
+> change, which I think is sufficient. [[done]] --[[Joey]]

response
diff --git a/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6/comment_1_f5187936924ab40a8298d6103ddd683b._comment b/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6/comment_1_f5187936924ab40a8298d6103ddd683b._comment
new file mode 100644
index 0000000..025d2ae
--- /dev/null
+++ b/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6/comment_1_f5187936924ab40a8298d6103ddd683b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-17T18:44:54Z"
+ content="""
+That is not an error message produced by etckeeper, you'll need to talk to
+whoever produced the rpm of etckeeper that you have installed.
+"""]]

diff --git a/doc/todo/etkeeper_warning_about_hardlinks_doesn__39__t_exclude_ignored_files.mdwn b/doc/todo/etkeeper_warning_about_hardlinks_doesn__39__t_exclude_ignored_files.mdwn
new file mode 100644
index 0000000..7e70e48
--- /dev/null
+++ b/doc/todo/etkeeper_warning_about_hardlinks_doesn__39__t_exclude_ignored_files.mdwn
@@ -0,0 +1,16 @@
+Etckeeper checks for possible hardlinks in the file `/etc/etckeeper/pre-commit.d/20warn-problem-files`
+
+but it doesn't seem to exclude the files that match the ".gitignore" directives.
+
+Tested:
+
+    # cat .gitignore | grep -i py
+    *.pyc
+    *.pyo
+
+
+    15:12 root@someserver:/etc/fail2ban/action.d
+    # ls -l smtp.pyc
+    -rw-r--r-- 2 root root 5921 Jul 13  2017 smtp.pyc
+
+It would be better, for monitoring reasons, to exclude all those files that fall in the .gitignore pattern, as they won't be tracked anyway.

diff --git a/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn b/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn
new file mode 100644
index 0000000..48de821
--- /dev/null
+++ b/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn
@@ -0,0 +1,10 @@
+I have installed version: 1.18.5
+Trying to update: yum update from epel.
+
+getting error:
+
+Error: Package: etckeeper-1.18.7-2.el6.noarch (epel)
+           Requires: hostname
+
+
+OS version: CentOS release 6.9 (Final)

response
diff --git a/doc/forum/Composite___47___multi-step_changes/comment_1_a381633b6acebfc83ca68eaa1e181840._comment b/doc/forum/Composite___47___multi-step_changes/comment_1_a381633b6acebfc83ca68eaa1e181840._comment
new file mode 100644
index 0000000..0df681e
--- /dev/null
+++ b/doc/forum/Composite___47___multi-step_changes/comment_1_a381633b6acebfc83ca68eaa1e181840._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-08T15:59:07Z"
+ content="""
+One way to accomplish this is to `git branch -f transaction master` at the
+start, and once all intermediate commits have been made (by etckeeper or by
+you), run `git reset transaction; etckeeper commit "transaction
+description"`.
+
+It's also sometimes handy to then generate a merge commit between the final
+transaction commit and the last intermediate commit; then you have both
+the transactions and all the intermediate steps accessible in git log; 
+the git history has a diamond shape.
+
+I'd be willing to consider patches along these lines..
+"""]]

Question on usage model / feature request
diff --git a/doc/forum/Composite___47___multi-step_changes.mdwn b/doc/forum/Composite___47___multi-step_changes.mdwn
new file mode 100644
index 0000000..d1d9c43
--- /dev/null
+++ b/doc/forum/Composite___47___multi-step_changes.mdwn
@@ -0,0 +1,32 @@
+I'd like to be able to `commit` a single change into etckeeper's VCS that reflected more than one `apt` action.
+
+As a developer I prefer to see commits representing a logically complete piece of work,
+not something that requires follow-on commits before the system is back in a sane / consistent state.
+
+Consider the case of installing Sublime Text for Linux (** - see bottom), 
+there are several steps, all of which are parts of a single logical action that should be committed as one operation into git (or whatever VCS).
+
+* wget ... | apt-key add -
+* apt-get install apt-transport-https
+* create  /etc/apt/sources.list.d/sublime-text.list
+* apt-get update
+* apt-get install sublime-text
+
+Ideally the work-flow would look like:
+
+* etckeeper begin-transaction
+* wget ... | apt-key add -
+* git add apt/trusted.gpg
+* apt-get install apt-transport-https
+  # etckeeper WARNS about uncommitted changes / transaction still open
+  # (instead of aborting)
+* create  /etc/apt/sources.list.d/sublime-text.list
+* git add      apt/sources.list.d/sublime-text.list
+* apt-get update
+  # etckeeper WARNS...
+* apt-get install sublime-text
+  # etckeeper WARNS...
+* etckeeper finish-transaction # commits to VCS
+
+
+(*) https://www.sublimetext.com/docs/3/linux_repositories.html

hardlink warning
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
index af5229b..f64a9c6 100644
--- a/doc/forum.mdwn
+++ b/doc/forum.mdwn
@@ -2,3 +2,14 @@ This is a place to discuss using etckeeper, share tips and tricks, etc.
 If you need help, advice, or anything, post about it here.
 
 [[!inline pages="forum/* and !*/Discussion" archive=yes rootpage=forum postformtext="Add a new thread titled:"]]
+
+I get this warning:
+
+etckeeper warning: hardlinked files could cause problems with git:
+PackageKit/events/post-transaction.d/README
+PackageKit/events/pre-transaction.d/README
+
+What kind of problems can happen?
+
+In my use case it is no problem if the hardlink gets lost and two individual files
+are in the repo.

fix link
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 346082c..25f7764 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -1,5 +1,5 @@
 etckeeper is available in git at `git://git.joeyh.name/etckeeper`, or
-[in gitweb](http://git.joeyh.name/?p=etckeeper.git). 
+[in gitweb](https://git.joeyh.name/index.cgi/etckeeper.git). 
 
 It's packaged in Debian, Ubuntu, Fedora, etc.
 

caps
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 2247f3c..1602c8e 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -17,8 +17,8 @@ understand the basics of working with version control.
 
 [[!sidebar content="""
 [[README]]  
-[[install]]  
-[[news]]  
-[[todo]]  
-[[forum]]  
+[[Install]]  
+[[News]]  
+[[Todo]]  
+[[Forum]]  
 """]]

add a forum
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
new file mode 100644
index 0000000..af5229b
--- /dev/null
+++ b/doc/forum.mdwn
@@ -0,0 +1,4 @@
+This is a place to discuss using etckeeper, share tips and tricks, etc.
+If you need help, advice, or anything, post about it here.
+
+[[!inline pages="forum/* and !*/Discussion" archive=yes rootpage=forum postformtext="Add a new thread titled:"]]
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 666983e..2247f3c 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -20,4 +20,5 @@ understand the basics of working with version control.
 [[install]]  
 [[news]]  
 [[todo]]  
+[[forum]]  
 """]]

what to do about all those debian proposed patches
diff --git a/doc/todo/decide_what_to_do_about_the_debian_patches.mdwn b/doc/todo/decide_what_to_do_about_the_debian_patches.mdwn
new file mode 100644
index 0000000..5bfc22f
--- /dev/null
+++ b/doc/todo/decide_what_to_do_about_the_debian_patches.mdwn
@@ -0,0 +1,76 @@
+There is a number of patches in the Debian BTS that has been pending
+since before I took over maintainership of the package. I am wondering
+what to do with them - a bunch seem relevant and I could bundle them
+in `debian/patches` but I am not sure I want to carry such a "fork" of
+etckeeper forever, so I would prefer to approve them here first.
+
+On the other hand, I do not want to flood you with 8 feature requests
+you have already seen. So I figured I would open a single todo item to
+quickly allow you to review the [patch set](https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Apatch&exclude=tags%3Apending&pend-exc=done&repeatmerged=no&src=etckeeper):
+
+ * #519420 etckeeper: Add option to force commit after apt run.
+ 
+   Hack to force an empty commit to keep track of package changes.
+
+   Last change: Apr 2009. Marked "wontfix" in 2014.
+ 
+ * #549354 etckeeper: don't warn about ignored files
+ 
+   git-specific patch available, not sure how it behaves with other
+   VCSes. seems to have at least another user (fmarier)
+
+   Last change: Oct 2010.
+
+ * #576915 30store-metadata: use GNUisms to achieve 1s runtime.
+ 
+   concerns about portability to solaris, is this still an issue?
+   
+   Last change: Apr 2010.
+
+ * #592158 etckeeper: Example for tracking installed packages
+ 
+   sample post-install hook to keep track of installed packages in
+   /etc. similar to #519420 - close?
+   
+   Last change: Aug 2010
+
+ * #612029 etckeeper: Example hook for generating GPG-encrypted bundle
+   after every commit
+   
+   another sample post-install hook to secretely ship a git bundle to
+   a backup server
+   
+   Last change: Feb 2011
+
+ * #613278 etckeeper: writing a commit message for the autocommit that
+   happens after apt
+   
+   patch for git, with possible patch for bzr as well, requiring
+   proposed upstream change for bzr, not merged.
+   
+   last change: Sep 2013
+   
+ * #698062 logout hook
+ 
+   yet *another* sample hook, by yours truly, add a new "logout"
+   subcommand that can be added to bash_logout scripts.
+   
+   last change: Jan 2013
+
+ * #777612 etckeeper should read XDG_CONFIG_HOME/git/config
+ 
+   look in standard locations for the git config, seems sound
+   
+   last change: Feb 2015
+
+So to simplify, there are those groups of proposed changes:
+
+ * sample hooks (592158, 612029, 698062)
+ * bugfixes (549354, 777612)
+ * features and improvements (519420, 576915, 613278)
+
+So any opinion about what to do with those? Should I submit them as
+separate issues? Or should I ask the original reporters to do that
+here? Or should I just close those issues?
+
+Thanks! -- [[anarcat]]

Correct spelling mistake.
diff --git a/doc/todo/etckeeper_with_git_breaks_update-manager_.mdwn b/doc/todo/etckeeper_with_git_breaks_update-manager_.mdwn
index b2bfe96..5ba0725 100644
--- a/doc/todo/etckeeper_with_git_breaks_update-manager_.mdwn
+++ b/doc/todo/etckeeper_with_git_breaks_update-manager_.mdwn
@@ -3,7 +3,7 @@
 
 I have configured etckeeper to use git. It works fine if I use apt-get or synaptic packet manager.
 
-But when the update-manger install new packet versions it ends with an "installation failed" message. When I check the status of the git repository in the etc directory, some changes are not commited, e.g.:
+But when the update-manger install new packet versions it ends with an "installation failed" message. When I check the status of the git repository in the etc directory, some changes are not committed, e.g.:
 
     On branch master
     Changes to be committed:

Correct spelling mistake.
diff --git a/doc/todo/push_remote_branch.mdwn b/doc/todo/push_remote_branch.mdwn
index a9c35dc..17cb514 100644
--- a/doc/todo/push_remote_branch.mdwn
+++ b/doc/todo/push_remote_branch.mdwn
@@ -9,4 +9,4 @@ I think that adding `PUSH_REMOTE` was a mistake. It would be better to
 remove it, and add to the readme an example of writing your own
 `/etc/etckeeper/commit.d/99push` script that does exactly the kind of
 pushing you want. The only reason I've not done so is it would break
-compatability for anyone using this feature. --[[Joey]]
+compatibility for anyone using this feature. --[[Joey]]

Correct spelling mistake.
diff --git a/doc/README.mdwn b/doc/README.mdwn
index 2607ef8..c57cadd 100644
--- a/doc/README.mdwn
+++ b/doc/README.mdwn
@@ -184,7 +184,7 @@ run "etckeeper init" to update file permissions.)
 	-lp:x:7:cupsys
 	+lp:x:7:
 
-Incidentially, this also means I have a backup of dodo's /etc on darkstar.
+Incidentally, this also means I have a backup of dodo's /etc on darkstar.
 So if darkstar is compromised, that data could be used to attack dodo
 too. On the other hand, if dodo's disk dies, I can restore it from this
 handy backup.

Added a comment: comment 2
diff --git a/doc/todo/Restore_metadata_at_checkout/comment_2_b862ace5417cdac371fe0d53bdcf4a2f._comment b/doc/todo/Restore_metadata_at_checkout/comment_2_b862ace5417cdac371fe0d53bdcf4a2f._comment
new file mode 100644
index 0000000..7fa4b4a
--- /dev/null
+++ b/doc/todo/Restore_metadata_at_checkout/comment_2_b862ace5417cdac371fe0d53bdcf4a2f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="max@ef057623bb9d28c59f71a915db505de5795c9d25"
+ nickname="max"
+ avatar="http://cdn.libravatar.org/avatar/359dbffc8765406159ef904eedde50be"
+ subject="comment 2"
+ date="2017-10-31T02:44:29Z"
+ content="""
+Okay, thanks for your reply! Actually my umask is more restrictive than the default, so privacy is not an issue here (Systemd bizarrely complains about files being too restricted...)
+"""]]

comment
diff --git a/doc/todo/Restore_metadata_at_checkout/comment_1_5fc68808d70b67dc66637864c10cfcff._comment b/doc/todo/Restore_metadata_at_checkout/comment_1_5fc68808d70b67dc66637864c10cfcff._comment
new file mode 100644
index 0000000..abd38a0
--- /dev/null
+++ b/doc/todo/Restore_metadata_at_checkout/comment_1_5fc68808d70b67dc66637864c10cfcff._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-28T14:44:55Z"
+ content="""
+Such a post-checkout hook makes sense, and yes, `etckeeper init` only
+restores file permissions when run in an existing repository.
+
+Do note that there's a window where files that are supposed to be private
+may be exposed, depending on your umask, before the permissions are fixed
+up. So I can't completely recommend doing this. It might be good to make
+it install a post-checkout hook that both fixes the permissions and warns
+that what the user is doing is not entirely safe.
+"""]]

diff --git a/doc/todo/Restore_metadata_at_checkout.mdwn b/doc/todo/Restore_metadata_at_checkout.mdwn
new file mode 100644
index 0000000..a28d70f
--- /dev/null
+++ b/doc/todo/Restore_metadata_at_checkout.mdwn
@@ -0,0 +1,14 @@
+Every time I switch a branch and files get replaced, they are not in the chmod they should be (because of my umask). So I've added a post-checkout hook "etckeeper init".
+
+Do I understand it right, that this doesn't do anything but setting the file permissions correctly, as per .etckeeper file?
+
+Saving metadata i.e. file permissions is the primary reason using etckeeper instead of plain git. What would speak against setting that up by default?
+
+
+---
+/etc/.git/hooks/post-checkout:
+
+    #!/bin/sh
+    # post-checkout hook for etckeeper, to restore metadata
+    set -e
+    etckeeper init -d /etc

Added a comment: make install
diff --git a/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_2_8524d920029e401175ab6d2fe1362cc5._comment b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_2_8524d920029e401175ab6d2fe1362cc5._comment
new file mode 100644
index 0000000..21aa24a
--- /dev/null
+++ b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_2_8524d920029e401175ab6d2fe1362cc5._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="http://roschacker.id.mail.ru/"
+ subject="make install"
+ date="2017-07-15T13:52:11Z"
+ content="""
+root@LEDE:~/etckeeper.branchable.com# make
+sed -i~ \"s/Version:.*/Version: $(perl -e '$_=<>;m/\((.*?)(-.*)?\)/;print $1;'<debian/changelog)/\" etckeeper.spec
+/bin/sh: perl: not found
+rm -f etckeeper.spec~
+sed -i~ \"s/Version:.*/Version: $(perl -e '$_=<>;m/\((.*?)(-.*)?\)/;print $1;' <debian/changelog)\\"/\" etckeeper
+/bin/sh: perl: not found
+rm -f etckeeper~
+python ./etckeeper-bzr/__init__.py build || echo \"** bzr support not built\"
+Traceback (most recent call last):
+  File \"./etckeeper-bzr/__init__.py\", line 6, in <module>
+    from bzrlib.errors import BzrError
+ImportError: No module named bzrlib.errors
+** bzr support not built
+python ./etckeeper-dnf/etckeeper.py build || echo \"** DNF support not built\"
+Traceback (most recent call last):
+  File \"./etckeeper-dnf/etckeeper.py\", line 10, in <module>
+    from dnfpluginscore import logger
+ImportError: No module named dnfpluginscore
+** DNF support not built
+root@LEDE:~/etckeeper.branchable.com#
+root@LEDE:~/etckeeper.branchable.com#
+root@LEDE:~/etckeeper.branchable.com# make install
+sed -i~ \"s/Version:.*/Version: $(perl -e '$_=<>;m/\((.*?)(-.*)?\)/;print $1;' <debian/changelog)\\"/\" etckeeper
+/bin/sh: perl: not found
+rm -f etckeeper~
+mkdir -p /etc/etckeeper/ /var/cache/etckeeper/
+cp -R *.d /etc/etckeeper/
+install  daily /etc/etckeeper/daily
+make: install: Command not found
+make: *** [Makefile:29: install] Error 127
+root@LEDE:~/etckeeper.branchable.com#
+"""]]

Added a comment: What dependencies we need?
diff --git a/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_1_9131efb9888659f72a55fc732c87a566._comment b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_1_9131efb9888659f72a55fc732c87a566._comment
new file mode 100644
index 0000000..a88f4bf
--- /dev/null
+++ b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/comment_1_9131efb9888659f72a55fc732c87a566._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://roschacker.id.mail.ru/"
+ subject="What dependencies we need?"
+ date="2017-07-15T13:09:41Z"
+ content="""
+python is NOT installed by default
+nither perl
+
+but git is present
+"""]]

diff --git a/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg.mdwn b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg.mdwn
new file mode 100644
index 0000000..46d6f38
--- /dev/null
+++ b/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg.mdwn
@@ -0,0 +1,5 @@
+Hello
+
+What we need to do (to code)
+for working etckeeper under LEDE/OpenWRT?
+

Added a comment: comment 3
diff --git a/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_3_d88dfbf82994d484a50a8fb751fc4c83._comment b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_3_d88dfbf82994d484a50a8fb751fc4c83._comment
new file mode 100644
index 0000000..c6494db
--- /dev/null
+++ b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_3_d88dfbf82994d484a50a8fb751fc4c83._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="truist"
+ avatar="http://cdn.libravatar.org/avatar/cbb99b0a9724faf8fc7f4464b7bfab11"
+ subject="comment 3"
+ date="2017-06-29T16:30:56Z"
+ content="""
+I see why I used `--cached` - because `30git-add` runs before this script, so the files to be added are always already cached by the time this script runs. Doing the diff without `--cached` wouldn't work.
+
+However, your solution is still better, in case users have customized the scripts. 
+"""]]

Added a comment: comment 2
diff --git a/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_2_21482b7d984aabd310c09539f1dc8f0b._comment b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_2_21482b7d984aabd310c09539f1dc8f0b._comment
new file mode 100644
index 0000000..6ac374b
--- /dev/null
+++ b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_2_21482b7d984aabd310c09539f1dc8f0b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="truist"
+ avatar="http://cdn.libravatar.org/avatar/cbb99b0a9724faf8fc7f4464b7bfab11"
+ subject="comment 2"
+ date="2017-06-29T16:17:33Z"
+ content="""
+Wow - I'm not sure how I missed that behavior. Sorry about that. And yes, it sounds like `etckeeper unclean` is a much better option.
+"""]]

Added a comment: never added this patch
diff --git a/doc/todo/Fix_warnings_on_netbsd/comment_1_03217ebec4076aa066df755c99ba92fd._comment b/doc/todo/Fix_warnings_on_netbsd/comment_1_03217ebec4076aa066df755c99ba92fd._comment
new file mode 100644
index 0000000..25ce37e
--- /dev/null
+++ b/doc/todo/Fix_warnings_on_netbsd/comment_1_03217ebec4076aa066df755c99ba92fd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://schmonz.livejournal.com/"
+ subject="never added this patch"
+ date="2017-06-28T17:43:39Z"
+ content="""
+pkgsrc had been on a really old version (1.3!) until mid-May, when Nathan sent me these patches. I brought us up to 1.18.5.1, saw that this patch was unneeded, and applied just [[the other one|Truly-quiet when there's nothing to commit]]. Hoping for a 1.18.7 distfile to appear (maybe [here](https://packages.debian.org/stretch/etckeeper)?) so I can keep pkgsrc at the latest.
+"""]]

close
diff --git a/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn
index d135afe..5732719 100644
--- a/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn
+++ b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn
@@ -29,3 +29,6 @@ index 2a2176a..bcd02df 100755
 ~~~
 
 Thank you!
+
+> [[closed|done]] because `etckeeper unclean` is a better way to do this.
+> --[[Joey]]

comment
diff --git a/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_1_22aeb26fb522fb0806a2791970369080._comment b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_1_22aeb26fb522fb0806a2791970369080._comment
new file mode 100644
index 0000000..610598d
--- /dev/null
+++ b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/comment_1_22aeb26fb522fb0806a2791970369080._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-28T16:33:30Z"
+ content="""
+That patch makes etckeeper only commit changes that have been 
+staged (eg added with `git add`). If a file has been changed,
+but not staged, `git diff --cached` will ignore the change,
+and it won't get committed. So the patch is broken.
+
+On debian, a daily cron job uses `etckeeper unclean` to determine if there
+are any changes in need of committing. That works with every VCS that
+etckeeper supports, and my suggestion is that netbsd use the same
+mechanism.
+"""]]
diff --git a/etckeeper.spec b/etckeeper.spec
index 3de5b98..880969b 100644
--- a/etckeeper.spec
+++ b/etckeeper.spec
@@ -1,5 +1,5 @@
 Name: etckeeper
-Version: 1.18.7
+Vaersion: 1.18.7
 Release: 4%{?dist}
 Summary: store /etc in git, mercurial, bzr or darcs
 

fixed long ago
diff --git a/doc/todo/Fix_warnings_on_netbsd.mdwn b/doc/todo/Fix_warnings_on_netbsd.mdwn
index f8e3796..1ed2b08 100644
--- a/doc/todo/Fix_warnings_on_netbsd.mdwn
+++ b/doc/todo/Fix_warnings_on_netbsd.mdwn
@@ -40,3 +40,8 @@ index f7c7580..f28d5ac 100755
 ~~~
 
 Thanks!
+
+> This change was already made to etckeeper back in 2014, there
+> is no "-not" in the etckeeper source code anywhere now.
+> I wonder why netbsd is apparently using such an out of date etckeeper.
+> Anyway, [[done]] --[[Joey]]

Describe patch for quieting commits when there's nothing to do
diff --git a/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn
new file mode 100644
index 0000000..d135afe
--- /dev/null
+++ b/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn
@@ -0,0 +1,31 @@
+I use etckeeper from [pkgsrc](http://pkgsrc.se/sysutils/etckeeper) on NetBSD in a nightly cron job. My configuration for git includes `-q` but that isn't enough to fully silence it when there's nothing to commit, so I get an email from cron every night, even when there's nothing to commit. Amitai (schmonz) applied this patch to pkgsrc, and I thought you might like it upstream.
+
+Note that the patch will always skip attempting the commit, if there is nothing to commit, which is maybe not what you intended. But it's the only way to actually get silent nightlies. If you wanted to preserve backwards compatibility, it would be tricky, I think.
+
+There are also more-efficient ways to do this; the `diff` could be run right at the top of this script, and the rest of it skipped. But I wanted to be minimally-invasive, so I did it this way. 
+
+~~~
+diff --git a/etckeeper/commit.d/50vcs-commit b/etckeeper/commit.d/50vcs-commit
+index 2a2176a..bcd02df 100755
+--- a/etckeeper/commit.d/50vcs-commit
++++ b/etckeeper/commit.d/50vcs-commit
+@@ -87,10 +87,12 @@ if [ "$VCS" = git ] && [ -d .git ]; then
+                        export GIT_COMMITTER_EMAIL
+                fi
+        fi
+-       if [ -n "$logfile" ]; then
+-               git commit $GIT_COMMIT_OPTIONS -F "$logfile"
+-       else
+-               git commit $GIT_COMMIT_OPTIONS
++       if ! git diff --cached --quiet; then
++               if [ -n "$logfile" ]; then
++                       git commit $GIT_COMMIT_OPTIONS -F "$logfile"
++               else
++                       git commit $GIT_COMMIT_OPTIONS
++               fi
+        fi
+ elif [ "$VCS" = hg ] && [ -d .hg ]; then
+        if [ -n "$USER" ]; then
+~~~
+
+Thank you!

Describe patch to fix netbsd warnings
diff --git a/doc/todo/Fix_warnings_on_netbsd.mdwn b/doc/todo/Fix_warnings_on_netbsd.mdwn
new file mode 100644
index 0000000..f8e3796
--- /dev/null
+++ b/doc/todo/Fix_warnings_on_netbsd.mdwn
@@ -0,0 +1,42 @@
+I use etckeeper from [pkgsrc](http://pkgsrc.se/sysutils/etckeeper) on NetBSD with a nightly cron job, and it generates warnings each night:
+
+~~~
+dnsdomainname: not found
+find: -not: unknown option
+find: -not: unknown option
+[master e4e5623] Daily autocommit
+ 5 files changed, 90 deletions(-)
+...and so on...
+~~~
+
+I've traced the issue to not-quite-POSIX args to `find` in `pre-commit.d/20warn-problem-files`, made a patch, and Amitai (schmonz) has applied the patch to the pkgsrc version. I thought you might want to include it at the source:
+
+~~~
+diff --git a/etckeeper/pre-commit.d/20warn-problem-files b/etckeeper/pre-commit.d/20warn-problem-files
+index f7c7580..f28d5ac 100755
+--- a/etckeeper/pre-commit.d/20warn-problem-files
++++ b/etckeeper/pre-commit.d/20warn-problem-files
+@@ -6,14 +6,14 @@ exclude_internal () {
+ }
+ 
+ if [ "$VCS" = bzr ] || [ "$VCS" = darcs ]; then
+-       special=$(find . -not -type d -not -type f -not -type l | exclude_internal) || true
+-       hardlinks=$(find . -type f -not -links 1 | exclude_internal ) || true
++       special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true
++       hardlinks=$(find . -type f ! -links 1 | exclude_internal ) || true
+ elif [ "$VCS" = hg ]; then
+-       special=$(find . -not -type d -not -type f -not -type l | exclude_internal) || true
+-       hardlinks=$(find . -type f -not -links 1 -exec hg status {} \; | exclude_internal ) || true
++       special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true
++       hardlinks=$(find . -type f ! -links 1 -exec hg status {} \; | exclude_internal ) || true
+ elif [ "$VCS" = git ]; then
+-       special=$(find . -not -type d -not -type f -not -type l -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true
+-       hardlinks=$(find . -type f -not -links 1 -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true
++       special=$(find . ! -type d ! -type f ! -type l -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true
++       hardlinks=$(find . -type f ! -links 1 -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true
+ else
+        special=""
+ fi
+~~~
+
+Thanks!

Work around git commit's lack of robustness, by providing reasonable default values for GIT_COMMITTER_EMAIL etc.
This was already done as part of the su/sudo handling, and is now always
done.
This commit was sponsored by Trenton Cronholm on Patreon.
diff --git a/commit.d/50vcs-commit b/commit.d/50vcs-commit
index 55f0db2..f970d3d 100755
--- a/commit.d/50vcs-commit
+++ b/commit.d/50vcs-commit
@@ -41,9 +41,16 @@ else
 fi
 
 if [ "$VCS" = git ] && [ -d .git ]; then
+	# When not su'd to root, still set environment variables, 
+	# since git's own code to determine the author and committer
+	# has several edge cases where it fails and would prevent the
+	# commit.
+	if [ -z "$USER" ]; then
+		USER="$(whoami)"
+	fi
 	if [ -n "$USER" ]; then
 		# Use user.name and user.email from the gitconfig belonging
-		# to the user who became root.
+		# to USER.
 		USER_HOME="$(getent passwd "$USER" | cut -d: -f6)"
 		if [ -n "$USER_HOME" ] && [ -e "$USER_HOME/.gitconfig" ]; then
 			if [ -z "$GIT_AUTHOR_NAME" ]; then
diff --git a/debian/changelog b/debian/changelog
index 23783bd..46df223 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+etckeeper (1.18.8) UNRELEASED; urgency=medium
+
+  * Work around git commit's lack of robustness, by providing
+    reasonable default values for GIT_COMMITTER_EMAIL etc.
+    This was already done as part of the su/sudo handling,
+    and is now always done.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 08 Jun 2017 13:22:01 -0400
+
 etckeeper (1.18.7) unstable; urgency=medium
 
   * Added some unit tests.
diff --git a/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
index 93177d8..5ddd8ad 100644
--- a/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
+++ b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
@@ -34,3 +34,5 @@ This is not Ansible-specific: the last two conditions will also arise in the dai
 
 
 IMO, considering how to document this behaviour shows it to be user-unfriendly.  Therefore, it would be simplest if etckeeper could fall back to using `$(id -un)`, once `$(tty)` fails.
+
+> Set `USER=$(whoami)`, for git only. [[done]] --[[Joey]]
diff --git a/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances/comment_1_f8399058ebbf3059000e6528296cc1e9._comment b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances/comment_1_f8399058ebbf3059000e6528296cc1e9._comment
new file mode 100644
index 0000000..16e907f
--- /dev/null
+++ b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances/comment_1_f8399058ebbf3059000e6528296cc1e9._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-08T17:00:19Z"
+ content="""
+What actually requires user.email be set under
+undocumented circumstances? git does. Personally, I feel this is a total
+misfeature on git's part; git commit should succeed under all
+configuraations. Every single program that automates `git commit`
+is potentially buggy otherwise.
+
+Anyway, yes, setting `USER=$(id -un)` (or whoami) would make
+the code that currently is used to handle sudo users be always
+run, and so git and any other VCSs that break in unusual circumstances
+would always work (at least as far as username and email goes, who knows
+what other requirements VCSs may have).
+
+The downside is that this could change etckeeper's behavior, since
+it would now be guessing at the user name and email, and may make
+different choices than git does.
+
+Setting USER would also impact the code for other VCSs than git. For
+example, the code for hg always sets HGUSER when USER is set. I don't know
+if the others VCSs are as picky as git; if this kind of breakage is not a
+problem for them it might be best to only set USER when using git.
+"""]]

add news item for etckeeper 1.18.7
diff --git a/doc/news/version_1.18.2.mdwn b/doc/news/version_1.18.2.mdwn
deleted file mode 100644
index fe38994..0000000
--- a/doc/news/version_1.18.2.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-etckeeper 1.18.2 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Use getent utility instead of perl. (Elan Ruusamäe)
-   * Initial FreeBSD support with pkgng plugin. (William Johansson)
-   * Fix README.md symlink in package (Sebastian Schmidt, Antoine Beaupré,
-     closes: #[791566](http://bugs.debian.org/791566))
-   * Fix typo of GIT\_COMMITTER\_EMAIL."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.7.mdwn b/doc/news/version_1.18.7.mdwn
new file mode 100644
index 0000000..8259825
--- /dev/null
+++ b/doc/news/version_1.18.7.mdwn
@@ -0,0 +1,8 @@
+etckeeper 1.18.7 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Added some unit tests.
+     Thanks, Henrik Riomar.
+   * etckeeper will work on systems that do not have perl installed.
+     (perl is still used when available as it's faster)
+     Thanks, William Johansson and radhus.
+   * Prevent LC\_ALL overriding the LC\_COLLATE used to sort metadata."""]]
\ No newline at end of file

diff --git a/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
index fc45abc..93177d8 100644
--- a/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
+++ b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
@@ -6,9 +6,31 @@ In common usage, this expectation is masked.  I believe the conditions for it br
 
 1. user.email is not set in git, AND
 2. the system hostname cannot be resolved to an FQDN, AND
-3. etckeeper is not run from sudo AND
-4. etckeeper is not run from a tty
+3. /etc/mailname does not exist (it is created by the Debian exim packages?) AND
+4. etckeeper is not run from sudo AND
+5. etckeeper is not run from a tty
+
+In this situation, etckeeper requires users to set `user.email` in /root/.gitconfig, or to have set it in /etc/.git/config immediately after `etckeeper init`.
+
+This is not Ansible-specific: the last two conditions will also arise in the daily autocommit script.
+
+    ● etckeeper.service - Autocommit of changes in /etc directory
+       Loaded: loaded (/lib/systemd/system/etckeeper.service; static; vendor preset: enabled)
+       Active: failed (Result: exit-code) since Sat 2017-06-03 00:22:20 BST; 5s ago
+         Docs: man:etckeeper(8)
+      Process: 2989 ExecStart=/etc/etckeeper/daily (code=exited, status=128)
+     Main PID: 2989 (code=exited, status=128)
+
+    Jun 03 00:22:20 unstable daily[2989]: Run
+    Jun 03 00:22:20 unstable daily[2989]:   git config --global user.email "you@example.com"
+    Jun 03 00:22:20 unstable daily[2989]:   git config --global user.name "Your Name"
+    Jun 03 00:22:20 unstable daily[2989]: to set your account's default identity.
+    Jun 03 00:22:20 unstable daily[2989]: Omit --global to set the identity only in this repository.
+    Jun 03 00:22:20 unstable daily[2989]: fatal: unable to auto-detect email address (got 'root@unstable.(none)')
+    Jun 03 00:22:20 unstable systemd[1]: etckeeper.service: Main process exited, code=exited, status=128/n/a
+    Jun 03 00:22:20 unstable systemd[1]: Failed to start Autocommit of changes in /etc directory.
+    Jun 03 00:22:20 unstable systemd[1]: etckeeper.service: Unit entered failed state.
+    Jun 03 00:22:20 unstable systemd[1]: etckeeper.service: Failed with result 'exit-code'.
 
-In this situation, etckeeper requires users to set `user.email` in /root/.gitconfig, or to have set it in /etc/.git/config immediately after `etckeeper init`.  As per link, these situations can occur when using Ansible.
 
 IMO, considering how to document this behaviour shows it to be user-unfriendly.  Therefore, it would be simplest if etckeeper could fall back to using `$(id -un)`, once `$(tty)` fails.

diff --git a/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
new file mode 100644
index 0000000..fc45abc
--- /dev/null
+++ b/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn
@@ -0,0 +1,14 @@
+[[https://unix.stackexchange.com/questions/368850/ansible-role-why-do-i-have-to-set-user-email-in-etckeeper/368851]]
+
+etckeeper expects that users set git `user.email`.  But it does not document this, or suggest a best way to do it.
+
+In common usage, this expectation is masked.  I believe the conditions for it breaking are:
+
+1. user.email is not set in git, AND
+2. the system hostname cannot be resolved to an FQDN, AND
+3. etckeeper is not run from sudo AND
+4. etckeeper is not run from a tty
+
+In this situation, etckeeper requires users to set `user.email` in /root/.gitconfig, or to have set it in /etc/.git/config immediately after `etckeeper init`.  As per link, these situations can occur when using Ansible.
+
+IMO, considering how to document this behaviour shows it to be user-unfriendly.  Therefore, it would be simplest if etckeeper could fall back to using `$(id -un)`, once `$(tty)` fails.

done link has to be in the page, not in the comment?
diff --git a/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd.mdwn b/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd.mdwn
index a9e3709..4d5b108 100644
--- a/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd.mdwn
+++ b/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd.mdwn
@@ -4,4 +4,4 @@ This is because git refuses to track symlinks to files which lie outside the git
 
 Supporting symlinks outside the repository is also required for /etc/alternatives.
 
-- Huh, I was 100% wrong. [done](../done). Some user error, I can't work out what though.
+- Huh, I was 100% wrong. [[done]]. Some user error, I can't work out what though.