diff --git a/doc/news/version_1.18.16.mdwn b/doc/news/version_1.18.16.mdwn
deleted file mode 100644
index 2c40958..0000000
--- a/doc/news/version_1.18.16.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-etckeeper 1.18.16 released with [[!toggle text="these changes"]]
-[[!toggleable text="""  * Improve sorting stability.
-  * Prefer mktemp over tempfile as the latter displays a deprecation
-    warning since debianutils 4.10.
-    Thanks, Luke Mlsna."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.21.mdwn b/doc/news/version_1.18.21.mdwn
new file mode 100644
index 0000000..ecc43ef
--- /dev/null
+++ b/doc/news/version_1.18.21.mdwn
@@ -0,0 +1,4 @@
+etckeeper 1.18.21 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Consistently use mktemp if available, falling back to tempfile
+    otherwise.
+    Thanks, Adam Dinwoodie"""]]
\ No newline at end of file

diff --git a/doc/forum/check__95__root_test_does_not_work_in_user__95__namespaces.mdwn b/doc/forum/check__95__root_test_does_not_work_in_user__95__namespaces.mdwn
new file mode 100644
index 0000000..7538c0d
--- /dev/null
+++ b/doc/forum/check__95__root_test_does_not_work_in_user__95__namespaces.mdwn
@@ -0,0 +1,7 @@
+when building etckeeper in void linux, which uses user_namespaces(7) to chroot, the tests 8 (and sometimes 7) fail.
+see https://github.com/void-linux/void-packages/pull/42192
+and https://github.com/void-linux/void-packages#chroot-methods
+
+this is (likely) due to the check_root test not detecting that the build is performed inside a chroot.
+
+any suggestion how one could improve that?

diff --git a/doc/todo/Pull_request:_Export_key_environment_variables_for_vcs_subcommand/comment_1_43f5a017d6575632d258a57eff429cb3._comment b/doc/todo/Pull_request:_Export_key_environment_variables_for_vcs_subcommand/comment_1_43f5a017d6575632d258a57eff429cb3._comment
new file mode 100644
index 0000000..82102a7
--- /dev/null
+++ b/doc/todo/Pull_request:_Export_key_environment_variables_for_vcs_subcommand/comment_1_43f5a017d6575632d258a57eff429cb3._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-08-07T17:47:11Z"
+ content="""
+Looking back at [[!commit 65eda73020e0aa6bf15e64106dae955bf17a41dd]], the
+initial idea of `etckeeper vcs` was to run the command in the same
+environment that etckeeper uses. Which it does do for `HOME` and a few
+other things.
+
+So I'm broadly in agreement that this might be a good idea. But copying
+86 lines of quite hairy code is certainly not a maintainable way to do it.
+
+There's also the question of whether a user might be surprised to find
+specific things that happen to be set in the `etckeeper commit` environment
+being set.
+
+Also worth bearing in mind that `etckeeper commit` needs to run
+successfully even if the host doesn't have a hostname configured or in the
+face of other problems that typically prevent git from committing. Because
+it's run by eg apt hooks, and generally is an abstraction layer where the
+user may not be comfortable setting up git. That does not really apply to
+`etckeeper vcs`, and so a certian amount of the code from `etckeeper
+commit` doesn't seem necessary in `etckeeper vcs`.
+
+(Also you have this line that was accidentially left in:
+	echo "Testing; \$USER: $USER"`
+)
+"""]]

diff --git a/doc/forum/List_of_files_or_directories_to_daily_auto_commit_or_commit_before_install.mdwn b/doc/forum/List_of_files_or_directories_to_daily_auto_commit_or_commit_before_install.mdwn
new file mode 100644
index 0000000..34c4768
--- /dev/null
+++ b/doc/forum/List_of_files_or_directories_to_daily_auto_commit_or_commit_before_install.mdwn
@@ -0,0 +1,5 @@
+Hello,
+
+There is a solution include in etckeeper that allow to create a list of files or directories that can be automatically commit even if we desactivate global daily autocommit or install before install ?
+
+Regards

diff --git a/doc/forum/move_git_directory_elsewhere__63__/comment_1_1a4787f587c13ec0ce7f59ff52a8ce66._comment b/doc/forum/move_git_directory_elsewhere__63__/comment_1_1a4787f587c13ec0ce7f59ff52a8ce66._comment
new file mode 100644
index 0000000..6ef359a
--- /dev/null
+++ b/doc/forum/move_git_directory_elsewhere__63__/comment_1_1a4787f587c13ec0ce7f59ff52a8ce66._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="ch-and-etckeeper.branchable.com@6e0ad263d7466ea3783deb474298632f286b1e3e"
+ nickname="ch-and-etckeeper.branchable.com"
+ avatar="http://cdn.libravatar.org/avatar/72e56d8e90557a374d5c1907319b48fc"
+ subject="Yes, it works"
+ date="2023-06-27T18:26:39Z"
+ content="""
+It works!
+
+In hindsight, I probably just should have tested it instead of bothering to ask the question, but hey, now you know the answer too!
+"""]]

diff --git a/doc/todo/Pull_request:_Export_key_environment_variables_for_vcs_subcommand.mdwn b/doc/todo/Pull_request:_Export_key_environment_variables_for_vcs_subcommand.mdwn
new file mode 100644
index 0000000..c74762d
--- /dev/null
+++ b/doc/todo/Pull_request:_Export_key_environment_variables_for_vcs_subcommand.mdwn
@@ -0,0 +1,3 @@
+Currently, the `vcs` subcommand does not export environment variables in the same way that the `commit` subcommand does.  It can be useful to have those environment variables in some cases, though, such as when you're using git and wanting to run a `revert` subcommand (e.g. with `$ sudo etckeeper vcs revert $REVISION`), as the `revert` functionality includes committing the reverted change.
+
+I submit [this pull request](https://github.com/Juanc1to/etckeeper/tree/vcs_export) as a possible strategy to implement this: it currently duplicates the environment export logic from the `commit` subcommand.  It might make sense to refactor this out into some sort of library, but I'm not really familiar enough with shell script project conventions (or the maintainer's style goals) to suggest a strategy for this.

diff --git a/doc/forum/move_git_directory_elsewhere__63__.mdwn b/doc/forum/move_git_directory_elsewhere__63__.mdwn
new file mode 100644
index 0000000..62d1f93
--- /dev/null
+++ b/doc/forum/move_git_directory_elsewhere__63__.mdwn
@@ -0,0 +1,7 @@
+To increase the reliability of our system (it has daily power outages), we've made the root partition read-only, and only make it writable when we're making a change.
+
+Etckeeper doesn't like it if /etc is read-only, and generates daily emails to root about it.
+
+One idea is to move /etc/.git to /var/etckeeper/.git and create a symlink in its place; would it work, or is git fussy about that sort of thing?
+
+Thanks

diff --git a/doc/todo/50vcs-commit:_add_double_quotes_around_options/comment_1_bece365157ae43694c251ff7866f62f0._comment b/doc/todo/50vcs-commit:_add_double_quotes_around_options/comment_1_bece365157ae43694c251ff7866f62f0._comment
new file mode 100644
index 0000000..8099d63
--- /dev/null
+++ b/doc/todo/50vcs-commit:_add_double_quotes_around_options/comment_1_bece365157ae43694c251ff7866f62f0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-13T15:01:39Z"
+ content="""
+Wouldn't this break providing multiple space-seperated 
+options in `GIT_COMMIT_OPTIONS`, when it previously worked?
+"""]]

diff --git a/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn b/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn
index 88d250b..d4e9e42 100644
--- a/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn
+++ b/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn
@@ -2,13 +2,17 @@ I'm using Arch Linux, and the version number of etckeeper is 1.18.20-2.
 
 Background information: I utilize GitHub to automatically push my /etc directory to a repository. However, when etckeeper uses my GitHub account's git author information, it affects the contribution graph. Unfortunately, GitHub doesn't offer an option to exclude a single repository from the contribution graph. As a result, I decided to modify the git author.
 
-Modifying the code directly is not considered good practice. Instead, I chose to modify the /etc/etckeeper/etckeeper.conf file. After the modification, the configuration looks like this: GIT_COMMIT_OPTIONS="--author=\"username <username@localhost>\"".
+Modifying the code directly is not considered good practice. Instead, I chose to modify the `/etc/etckeeper/etckeeper.conf` file. After the modification, the configuration looks like this:
 
-When I execute the etckeeper commit command, it displays the following error: "fatal: --author '"username' is not 'Name <email>' and matches no existing author".
+`GIT_COMMIT_OPTIONS="--author=\"username <username@localhost>\""`
+
+When I execute the `etckeeper commit` command, it displays the following error:
+
+`fatal: --author '"username' is not 'Name <email>' and matches no existing author`
 
 Upon inspecting the code, I discovered that the commit.d/50vcs-commit script requires fixing. Specifically, double quotes need to be added around $GIT_COMMIT_OPTIONS. After including the double quotes, etckeeper functions as expected.
 
-I applied the same modification to HG_COMMIT_OPTIONS, BZR_COMMIT_OPTIONS, and DARCS_COMMIT_OPTIONS. The resulting patch is provided below:
+I applied the same modification to $HG_COMMIT_OPTIONS, $BZR_COMMIT_OPTIONS, and $DARCS_COMMIT_OPTIONS. The resulting patch is provided below:
 
 
 ```

diff --git a/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn b/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn
new file mode 100644
index 0000000..88d250b
--- /dev/null
+++ b/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn
@@ -0,0 +1,65 @@
+I'm using Arch Linux, and the version number of etckeeper is 1.18.20-2.
+
+Background information: I utilize GitHub to automatically push my /etc directory to a repository. However, when etckeeper uses my GitHub account's git author information, it affects the contribution graph. Unfortunately, GitHub doesn't offer an option to exclude a single repository from the contribution graph. As a result, I decided to modify the git author.
+
+Modifying the code directly is not considered good practice. Instead, I chose to modify the /etc/etckeeper/etckeeper.conf file. After the modification, the configuration looks like this: GIT_COMMIT_OPTIONS="--author=\"username <username@localhost>\"".
+
+When I execute the etckeeper commit command, it displays the following error: "fatal: --author '"username' is not 'Name <email>' and matches no existing author".
+
+Upon inspecting the code, I discovered that the commit.d/50vcs-commit script requires fixing. Specifically, double quotes need to be added around $GIT_COMMIT_OPTIONS. After including the double quotes, etckeeper functions as expected.
+
+I applied the same modification to HG_COMMIT_OPTIONS, BZR_COMMIT_OPTIONS, and DARCS_COMMIT_OPTIONS. The resulting patch is provided below:
+
+
+```
+diff --git a/commit.d/50vcs-commit b/commit.d/50vcs-commit
+index a76eb7e..8ac8581 100755
+--- a/commit.d/50vcs-commit
++++ b/commit.d/50vcs-commit
+@@ -109,9 +109,9 @@ if [ "$VCS" = git ] && [ -d .git ]; then
+ 	fi
+ 
+ 	if [ -n "$logfile" ]; then
+-		git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F "$logfile"
++		git $GIT_GC_OPTIONS commit "$GIT_COMMIT_OPTIONS" -F "$logfile"
+ 	else
+-		git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS
++		git $GIT_GC_OPTIONS commit "$GIT_COMMIT_OPTIONS"
+ 	fi
+ elif [ "$VCS" = hg ] && [ -d .hg ]; then
+ 	if [ -n "$USER" ]; then
+@@ -123,9 +123,9 @@ elif [ "$VCS" = hg ] && [ -d .hg ]; then
+ 		export HGUSER
+ 	fi
+ 	if [ -n "$logfile" ]; then
+-		hg commit $HG_COMMIT_OPTIONS -l "$logfile"
++		hg commit "$HG_COMMIT_OPTIONS" -l "$logfile"
+ 	else
+-		hg commit $HG_COMMIT_OPTIONS
++		hg commit "$HG_COMMIT_OPTIONS"
+ 	fi
+ elif [ "$VCS" = bzr ] && [ -d .bzr ]; then
+ 	if [ -z "$EMAIL" ] && [ -n "$USER" ]; then
+@@ -135,17 +135,17 @@ elif [ "$VCS" = bzr ] && [ -d .bzr ]; then
+ 		bzr whoami >/dev/null 2>&1 || export EMAIL="$ORIG_USER <$ORIG_USER@$hostname>"
+ 	fi
+ 	if [ -n "$logfile" ]; then
+-		bzr commit $BZR_COMMIT_OPTIONS -F "$logfile"
++		bzr commit "$BZR_COMMIT_OPTIONS" -F "$logfile"
+ 	else
+-		bzr commit --quiet $BZR_COMMIT_OPTIONS
++		bzr commit --quiet "$BZR_COMMIT_OPTIONS"
+ 	fi
+ elif [ "$VCS" = darcs ] && [ -d _darcs ]; then
+ 	if [ -z "$USER" ]; then
+ 		USER=root
+ 	fi
+ 	if [ -n "$logfile" ]; then
+-		darcs record --author="$USER" $DARCS_COMMIT_OPTIONS --logfile="$logfile"
++		darcs record --author="$USER" "$DARCS_COMMIT_OPTIONS" --logfile="$logfile"
+ 	else
+-		darcs record --author="$USER" $DARCS_COMMIT_OPTIONS
++		darcs record --author="$USER" "$DARCS_COMMIT_OPTIONS"
+ 	fi
+ fi
+```

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_6_cc18dab78617cec7efddb8b0450f7f07._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_6_cc18dab78617cec7efddb8b0450f7f07._comment
new file mode 100644
index 0000000..ab6aca9
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_6_cc18dab78617cec7efddb8b0450f7f07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pulk"
+ avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443"
+ subject="comment 6"
+ date="2023-04-25T05:43:57Z"
+ content="""
+Thanks! That solved the issue. I did not remember that I had previously attempted to add it as submodule to workaround the issue.
+"""]]

diff --git a/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail/comment_1_16b78a25b142a7b9f8cfc52e584a3a22._comment b/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail/comment_1_16b78a25b142a7b9f8cfc52e584a3a22._comment
new file mode 100644
index 0000000..e8d2daf
--- /dev/null
+++ b/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail/comment_1_16b78a25b142a7b9f8cfc52e584a3a22._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-21T16:10:58Z"
+ content="""
+`etckeeper commit` is what the cron job runs. That does not run
+`git gc`.
+
+I don't think a git commit triggers a gc either, normmally.
+
+Have you perhaps added a hook or something that causes the git gc?
+"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_5_b6a7557835e91cf2e8f362913b6fc6ee._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_5_b6a7557835e91cf2e8f362913b6fc6ee._comment
new file mode 100644
index 0000000..00127b5
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_5_b6a7557835e91cf2e8f362913b6fc6ee._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-04-21T16:02:43Z"
+ content="""
+Your repo has already been added as a submodule. That's why git commit is
+complaining about it.
+
+If you put it in /etc/.gitignore before `etckeeper commit`,
+it will be ignored from the beginning.
+
+At this point you will need to remove the submodule as well as ignoring it.
+
+I was a little surprised to see etckeeper adding git repos within /etc
+as submodules, but it turns out that `git add --all` or `git add .` do add
+submodules that way.
+"""]]

diff --git a/doc/forum/intended_behavior_of_the_sudo_integration__63__/comment_1_a610753a92db835cdeaf3b870b7c72a5._comment b/doc/forum/intended_behavior_of_the_sudo_integration__63__/comment_1_a610753a92db835cdeaf3b870b7c72a5._comment
new file mode 100644
index 0000000..b433743
--- /dev/null
+++ b/doc/forum/intended_behavior_of_the_sudo_integration__63__/comment_1_a610753a92db835cdeaf3b870b7c72a5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-21T15:53:20Z"
+ content="""
+When user.email is not set in the global git config, 
+etckeeper sets `GIT_COMMITTER_EMAIL` to
+
+	`whoami`"@$hostname"
+
+Where $hostname is `hostname` with `dnsdomainname` added as the domain if
+that outputs anything.
+
+It's possible etckeeper could be improved, but I don't have a sufficiently
+broken system to see it fail, so patches or further analysis would be up to
+you.
+"""]]

diff --git a/doc/forum/intended_behavior_of_the_sudo_integration.mdwn b/doc/forum/intended_behavior_of_the_sudo_integration__63__.mdwn
similarity index 100%
rename from doc/forum/intended_behavior_of_the_sudo_integration.mdwn
rename to doc/forum/intended_behavior_of_the_sudo_integration__63__.mdwn

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fb987b5a4ea73f83d01536f60f301a1a._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fb987b5a4ea73f83d01536f60f301a1a._comment
new file mode 100644
index 0000000..319d257
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fb987b5a4ea73f83d01536f60f301a1a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="pulk"
+ avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443"
+ subject="comment 4"
+ date="2023-03-16T14:18:17Z"
+ content="""
+Unfortunately that does not work. I tried all these in /etc/.gitignore:
+     
+     myrepo
+     myrepo/*
+     /myrepo
+     /myrepo/*
+     
+But I still get the error each time.
+
+"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_7d809c9c48aed545ed31240befbe9b2c._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_7d809c9c48aed545ed31240befbe9b2c._comment
deleted file mode 100644
index d8d2696..0000000
--- a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_7d809c9c48aed545ed31240befbe9b2c._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="pulk"
- avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443"
- subject="comment 4"
- date="2023-03-16T14:17:04Z"
- content="""
-Unfortunately that does not work. I tried all these in /etc/.gitignore:
-    myrepo 
-    myrepo/*
-    /myrepo
-    /myrepo/*
-
-But I still get the error each time.
-
-"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_7d809c9c48aed545ed31240befbe9b2c._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_7d809c9c48aed545ed31240befbe9b2c._comment
new file mode 100644
index 0000000..d8d2696
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_7d809c9c48aed545ed31240befbe9b2c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="pulk"
+ avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443"
+ subject="comment 4"
+ date="2023-03-16T14:17:04Z"
+ content="""
+Unfortunately that does not work. I tried all these in /etc/.gitignore:
+    myrepo 
+    myrepo/*
+    /myrepo
+    /myrepo/*
+
+But I still get the error each time.
+
+"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fcbe63063808e916aec7f47996b14d28._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fcbe63063808e916aec7f47996b14d28._comment
deleted file mode 100644
index 3f57eaa..0000000
--- a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fcbe63063808e916aec7f47996b14d28._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="pulk"
- avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443"
- subject="comment 4"
- date="2023-03-16T14:15:06Z"
- content="""
-Unfortunately that does not work. I tried all these in /etc/.gitignore:
-myrepo
-myrepo/*
-/myrepo
-/myrepo/*
-
-But I still get the error each time.
-"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fcbe63063808e916aec7f47996b14d28._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fcbe63063808e916aec7f47996b14d28._comment
new file mode 100644
index 0000000..3f57eaa
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_4_fcbe63063808e916aec7f47996b14d28._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="pulk"
+ avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443"
+ subject="comment 4"
+ date="2023-03-16T14:15:06Z"
+ content="""
+Unfortunately that does not work. I tried all these in /etc/.gitignore:
+myrepo
+myrepo/*
+/myrepo
+/myrepo/*
+
+But I still get the error each time.
+"""]]

diff --git a/doc/forum/intended_behavior_of_the_sudo_integration.mdwn b/doc/forum/intended_behavior_of_the_sudo_integration.mdwn
new file mode 100644
index 0000000..29397a2
--- /dev/null
+++ b/doc/forum/intended_behavior_of_the_sudo_integration.mdwn
@@ -0,0 +1,5 @@
+I noticed that with the `sudo` integration, the author will be set to the
+administrator. However, the commiter is still using the automatically-generated
+email address for root user. The issue is that I still need to set the full name
+for that “user”. How about also generating its full name? Or simply use the
+administrator as both author and commiter?

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_3_39cb7f40edffb43b79fdb275670ffbd9._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_3_39cb7f40edffb43b79fdb275670ffbd9._comment
new file mode 100644
index 0000000..b65c5a2
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_3_39cb7f40edffb43b79fdb275670ffbd9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="me_and"
+ avatar="http://cdn.libravatar.org/avatar/f8647c2810c056bbdb8857117708ae3d"
+ subject="comment 3"
+ date="2023-03-02T20:46:48Z"
+ content="""
+In that case, I'd recommend just having the directory ignored:
+
+```
+sudo sed -i 1i/myrepo /etc/.gitignore
+```
+"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_2_a9d66633132fe5d135499720e0beaaa3._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_2_a9d66633132fe5d135499720e0beaaa3._comment
new file mode 100644
index 0000000..6b205e4
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_2_a9d66633132fe5d135499720e0beaaa3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pulk"
+ avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443"
+ subject="Comment 2"
+ date="2023-02-28T11:41:37Z"
+ content="""
+Hi! And thanks for the tip. I think I am okay with the first and second option (ignore the dir completely or have as submodule) you provided. And I would indeed like to know about any other error messages, I do not wish to ignore them completely.
+"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_1_5eb9fcc0e3384f702da7e188b19c3858._comment b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_1_5eb9fcc0e3384f702da7e188b19c3858._comment
new file mode 100644
index 0000000..26a9af6
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/comment_1_5eb9fcc0e3384f702da7e188b19c3858._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="me_and"
+ avatar="http://cdn.libravatar.org/avatar/f8647c2810c056bbdb8857117708ae3d"
+ subject="comment 1"
+ date="2023-02-23T13:27:23Z"
+ content="""
+What are you trying to achieve here?  I'm not sure what your goal is from the question. Would you rather…
+
+- Have etckeeper ignore the `/etc/myrepo` directory entirely
+- Have etckeeper automatically commit changes to `/etc/myrepo` as a submodule, then automatically commit submodule changes to the `/etc` repository
+- Have etckeeper not run daily commits at all
+- Something else…
+
+If you _just_ want to disable the non-zero exit status, you can change `/etc/etckeeper/commit.d/50vcs-commit` to suppress the exit status.  To do that, change the following lines:
+
+```
+        if [ -n \"$logfile\" ]; then
+                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F \"$logfile\"
+        else
+                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS
+        fi
+```
+
+to
+
+```
+        if [ -n \"$logfile\" ]; then
+                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F \"$logfile\" || :
+        else
+                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS || :
+        fi
+```
+
+But all that will do is prevent any errors from being reported, which I suspect isn't what you're after! All `etckeeper commit` is doing is running the scripts in `/etc/etckeeper/commit`, though, so you should be able to change it to do whatever you want just by editing those scripts.
+"""]]

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
index 3f79cc8..7c5d11a 100644
--- a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
@@ -4,14 +4,14 @@ I've attempted to add the repo as git submodule in /etc/.gitmodules and tried to
 
 If I have a git repo in /etc/myrepo:
 
-# etckeeper commit "daily autocommit"
-On branch master
-Changes not staged for commit:
-  (use "git add <file>..." to update what will be committed)
-  (use "git restore <file>..." to discard changes in working directory)
-  (commit or discard the untracked or modified content in submodules)
-	modified:   myrepo (untracked content)
+    # etckeeper commit "daily autocommit"
+    On branch master
+    Changes not staged for commit:
+      (use "git add <file>..." to update what will be committed)
+      (use "git restore <file>..." to discard changes in working directory)
+      (commit or discard the untracked or modified content in submodules)
+	    modified:   myrepo (untracked content)
 
-no changes added to commit (use "git add" and/or "git commit -a")
-# echo $?
-1
+    no changes added to commit (use "git add" and/or "git commit -a")
+    # echo $?
+    1

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
index 0f94c42..3f79cc8 100644
--- a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
@@ -1,6 +1,6 @@
 I did some research and found out that there is no good way to avoid etckeeper commit "daily autocommit" exiting with status code other than zero if there is a git repository under the /etc hierarchy? This causes the /etc/cron.daily/etckeeper to send an e-mail every day with body "run-parts: /etc/cron.daily/etckeeper exited with return code 1."
 
-I've attempted to add the repo as git submodule in /etc/.gitmodules and tried to add "-path ./local -prune -o" to the NOVCS in /etc/etckeeper/pre-commit.d/30store-metadata but neither of these fixed the issue.
+I've attempted to add the repo as git submodule in /etc/.gitmodules and tried to add "-path ./myrepo -prune -o" to the NOVCS in /etc/etckeeper/pre-commit.d/30store-metadata but neither of these fixed the issue.
 
 If I have a git repo in /etc/myrepo:
 

diff --git a/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
new file mode 100644
index 0000000..0f94c42
--- /dev/null
+++ b/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn
@@ -0,0 +1,17 @@
+I did some research and found out that there is no good way to avoid etckeeper commit "daily autocommit" exiting with status code other than zero if there is a git repository under the /etc hierarchy? This causes the /etc/cron.daily/etckeeper to send an e-mail every day with body "run-parts: /etc/cron.daily/etckeeper exited with return code 1."
+
+I've attempted to add the repo as git submodule in /etc/.gitmodules and tried to add "-path ./local -prune -o" to the NOVCS in /etc/etckeeper/pre-commit.d/30store-metadata but neither of these fixed the issue.
+
+If I have a git repo in /etc/myrepo:
+
+# etckeeper commit "daily autocommit"
+On branch master
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+  (commit or discard the untracked or modified content in submodules)
+	modified:   myrepo (untracked content)
+
+no changes added to commit (use "git add" and/or "git commit -a")
+# echo $?
+1

diff --git a/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail.mdwn b/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail.mdwn
new file mode 100644
index 0000000..bc9fb38
--- /dev/null
+++ b/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail.mdwn
@@ -0,0 +1,19 @@
+Hi there,
+
+I'm using etckeeper 1.18.17 on Ubuntu kinetic (22.10).
+
+Every few days (roughly 4-8 days, the exact frequency varies, probably depending on how much I change in /etc) I get a mail from Anacron that has the following content:
+
+```
+/etc/cron.daily/etckeeper:
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+```
+
+I guess the automatic garbage collection of git is executed, which prints this unimportant bit of information to stdout, thus triggering an e-mail by Anacron.
+
+Since there is no actual problem, we should suppress this output, so that no mail will be sent.
+One idea would be to just run 'git gc --auto' on a daily basis, I guess?
+
+Cheers,
+Patrick.

diff --git a/CHANGELOG b/CHANGELOG
index de87db4..893477f 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,11 @@
+etckeeper (1.18.21) UNRELEASED; urgency=medium
+
+  * Consistently use mktemp if available, falling back to tempfile
+    otherwise.
+    Thanks, Adam Dinwoodie
+
+ -- Joey Hess <id@joeyh.name>  Mon, 16 Jan 2023 11:42:05 -0400
+
 etckeeper (1.18.20) upstream; urgency=medium
 
   * Fix a reversion in etckeeper init in version 1.18.19.
diff --git a/doc/todo/Consistent_tempfile_creation.mdwn b/doc/todo/Consistent_tempfile_creation.mdwn
index ed2cc3e..a27fd23 100644
--- a/doc/todo/Consistent_tempfile_creation.mdwn
+++ b/doc/todo/Consistent_tempfile_creation.mdwn
@@ -4,3 +4,8 @@ I don't particularly mind how this is resolved, but I'd like it resolved in some
 
 - [Allow either `mktemp` or `tempfile` everywhere](https://github.com/me-and/etckeeper/commit/96d4da2314ad64147835554371d04372cb4a4612) (best for backwards compatibility, as it'll keep working for folk who don't have `mktemp`)
 - [Consistently assume `mktemp` is available](https://github.com/me-and/etckeeper/commit/3fb703588997590fec4776fb91e3b119ab3f75f9) (best for simplicity)
+
+> Thanks, I've applied the first patch. It looks like all the code that
+> assumed mktemp was available only ran when using darcs, so there are
+> presumably systems where mktemp is not available that the second patch
+> would break. [[done]] --[[Joey]]

diff --git a/doc/todo/Consistent_tempfile_creation.mdwn b/doc/todo/Consistent_tempfile_creation.mdwn
new file mode 100644
index 0000000..ed2cc3e
--- /dev/null
+++ b/doc/todo/Consistent_tempfile_creation.mdwn
@@ -0,0 +1,6 @@
+Currently etckeeper has two different mechanisms for creating temporary files.  There's no clear reason for that, and it caught me out when I was trying to update some of the scripts for my own purposes.
+
+I don't particularly mind how this is resolved, but I'd like it resolved in some consistent fashion! I've made two patches for two different resolutions:
+
+- [Allow either `mktemp` or `tempfile` everywhere](https://github.com/me-and/etckeeper/commit/96d4da2314ad64147835554371d04372cb4a4612) (best for backwards compatibility, as it'll keep working for folk who don't have `mktemp`)
+- [Consistently assume `mktemp` is available](https://github.com/me-and/etckeeper/commit/3fb703588997590fec4776fb91e3b119ab3f75f9) (best for simplicity)

diff --git a/doc/news/version_1.18.15.mdwn b/doc/news/version_1.18.15.mdwn
deleted file mode 100644
index 5431cc9..0000000
--- a/doc/news/version_1.18.15.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-etckeeper 1.18.15 released with [[!toggle text="these changes"]]
-[[!toggleable text="""  * 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.
-  * If gc.auto is not configured, override the default to make it gc
-    ten times more frequently, to avoid wasting space with loose objects.
-  * update-ignore: Preserve permissions from any preexisting VCS ignore file.
-    Thanks, Austin Chu.
-  * Removed the debian directory from the upstream source package as it's
-    not being maintained; see the debian package for an up-to-date one.
-  * debian/changelog moved to CHANGELOG and debian/copyright to COPYRIGHT."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.20.mdwn b/doc/news/version_1.18.20.mdwn
new file mode 100644
index 0000000..b3d5cc6
--- /dev/null
+++ b/doc/news/version_1.18.20.mdwn
@@ -0,0 +1,3 @@
+etckeeper 1.18.20 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Fix a reversion in etckeeper init in version 1.18.19.
+    Thanks, Georgy Yakovlev"""]]
\ No newline at end of file

diff --git a/doc/news/version_1.18.14.mdwn b/doc/news/version_1.18.14.mdwn
deleted file mode 100644
index 72862fe..0000000
--- a/doc/news/version_1.18.14.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-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.19.mdwn b/doc/news/version_1.18.19.mdwn
new file mode 100644
index 0000000..cb01a09
--- /dev/null
+++ b/doc/news/version_1.18.19.mdwn
@@ -0,0 +1,9 @@
+etckeeper 1.18.19 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Added support for Gentoo (emerge, qlist, and cave)
+    Thanks, Sam James
+  * Skip running pre-commit hook inside linked worktrees,
+    to avoid it updating .etckeeper with the permissions of files
+    not in /etc.
+    Thanks, Håkon Løvdal
+  * commit: Run bzr with --quiet, since it outputs non-errors to stderr.
+    Closes: #[1018874](http://bugs.debian.org/1018874)"""]]
\ No newline at end of file

diff --git a/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts./comment_1_2e5c41b9d32669974703285279c05784._comment b/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts./comment_1_2e5c41b9d32669974703285279c05784._comment
new file mode 100644
index 0000000..47e7e4e
--- /dev/null
+++ b/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts./comment_1_2e5c41b9d32669974703285279c05784._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-12-14T18:02:09Z"
+ content="""
+Since I'm not in a position to test this myself, it would be great if you
+could develop a patch, test it, and send the patch.
+"""]]

diff --git a/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts..mdwn b/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts..mdwn
new file mode 100644
index 0000000..03adfa4
--- /dev/null
+++ b/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts..mdwn
@@ -0,0 +1,21 @@
+The pacman hooks that etckeeper use only trigger if a package changes a file in /etc. This breaks when a package only changes /etc in it's post-install script.
+
+An example of this is archlinux-keyring, which runs a post install script to update the gpg trust db in /etc/pacman.
+
+The solution is to change the hooks to always run. Instead of:
+
+```
+Type = Path
+Target = etc/*
+```
+
+use something like:
+
+```
+Type = Package
+Target = *
+```
+
+At least when using git, `etckeeper pre-install` and `etckeeper post-install` are quick enough on my computer that running when not needed is not a big deal.
+
+Here is the Arch Linux bug about this: https://bugs.archlinux.org/task/76826

diff --git a/CHANGELOG b/CHANGELOG
index 2732870..20f5c18 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -2,6 +2,10 @@ etckeeper (1.18.19) UNRELEASED; urgency=medium
 
   * Added support for Gentoo (emerge, qlist, and cave)
     Thanks, Sam James
+  * Skip running pre-commit hook inside linked worktrees,
+    to avoid it updating .etckeeper with the permissions of files
+    not in /etc.
+    Thanks, Håkon Løvdal
 
  -- Joey Hess <id@joeyh.name>  Tue, 04 Oct 2022 12:35:28 -0400
 
diff --git a/doc/todo/Skip_running_pre-commit_hook_inside_linked_worktrees.mdwn b/doc/todo/Skip_running_pre-commit_hook_inside_linked_worktrees.mdwn
index 8075b85..15b516e 100644
--- a/doc/todo/Skip_running_pre-commit_hook_inside_linked_worktrees.mdwn
+++ b/doc/todo/Skip_running_pre-commit_hook_inside_linked_worktrees.mdwn
@@ -5,3 +5,5 @@ This could be done by cloning the repository and add it as a remote instead, but
 However the pre-commit hook messes things up when it is being run inside the linked worktree as well. It really should only run in the main worktree.
 
 Could you please merge the [worktree](https://github.com/hlovdal/etkeeper/compare/master...worktree) branch which contains one commit that adds a check to avoid running the pre-commit hook in linked worktrees?
+
+> Good patch, [[done]]! --[[Joey]]

diff --git a/doc/forum/Prevent_hook_running_during_rebase/comment_1_101f16d09f46b477811b7c864abbc8bb._comment b/doc/forum/Prevent_hook_running_during_rebase/comment_1_101f16d09f46b477811b7c864abbc8bb._comment
new file mode 100644
index 0000000..56da5ae
--- /dev/null
+++ b/doc/forum/Prevent_hook_running_during_rebase/comment_1_101f16d09f46b477811b7c864abbc8bb._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="hlovdal"
+ nickname="kode"
+ avatar="http://cdn.libravatar.org/avatar/e513ee57b6b0d2c0ae8dfa4b9e85f566"
+ subject="Use git worktree"
+ date="2022-11-27T22:50:32Z"
+ content="""
+While cloning and pulling between repos works, it is as you mentioned a bit cumbersome. What works much better is to create a lightweight [worktree](https://git-scm.com/docs/git-worktree), e.g. `git worktree add /root/etc.worktree main.worktree`. Then `/etc` and `/root/etc.worktree` shares all commits and sort of works like instantly synchronised clones. The only limitation is that the same branch cannot be checked out in both worktrees (I use `main.worktree` as a shadow of `main`).
+
+With that the update scenario will be like
+
+`cd /root/worktree`
+
+`git checkout main.worktree   # Probably default and not needed`
+
+`git merge --ff main # Bring it up to date`
+
+`git rebase --interactive HEAD~10   # Or whatever history modification you want to use`
+
+`cd /etc`
+
+Finish with either `git merge main.worktree`
+or `git reset --hard main.worktree   # NB! reset --hard is a command that might cause you to loose data if you are not careful.`
+
+I mainly use worktree to painlessly resolve new `*.rpmnew` files which are created if a package is updated and a config file update would overwrite some custom non-package modification, e.g say for instance you have changed `GIT_COMMIT_OPTIONS` in `etckeeper.conf` and a newer version of etckeeper has some other update to that config file. If it is the first time I resolve a update conflict I create a branch `rpmnew/etckeeper.conf` from a commit right before I made the `GIT_COMMIT_OPTIONS` modification (which might have been a while ago, so resetting back to that inside /etc would likely be a disaster. Inside a linked worktree there is no problem). Then I overwrite `/root/etc.worktree/etckeeper/etckeeper.conf` with `/etc/etckeeper/etckeeper.conf.rpmnew` and check in. Then the final step is `git checkout main.worktree && git merge rpmnew/etckeeper.conf`. This could potentially result in merge conflicts, but there are excellent tools like [KDiff3](https://kdiff3.sourceforge.net/) to [use for that](https://github.com/hlovdal/git-resolve-conflict-using-kdiff3).
+
+
+The problem with the pre-commit hook still applies in this scenario, but I have just [asked for a patch to be applied that will prevent the hook from running inside linked worktrees](https://etckeeper.branchable.com/todo/Skip_running_pre-commit_hook_inside_linked_worktrees/).
+
+
+"""]]

diff --git a/doc/todo/Skip_running_pre-commit_hook_inside_linked_worktrees.mdwn b/doc/todo/Skip_running_pre-commit_hook_inside_linked_worktrees.mdwn
new file mode 100644
index 0000000..8075b85
--- /dev/null
+++ b/doc/todo/Skip_running_pre-commit_hook_inside_linked_worktrees.mdwn
@@ -0,0 +1,7 @@
+Adding a git [worktree](https://git-scm.com/docs/git-worktree) is a great way to being able to change the version history without changing all the other files under `/etc` to some arbitrary old version while doing interactive rebases etc. With a worktree you can do all the work there and then merge in the final result in a clean operation in `/etc` later on.
+
+This could be done by cloning the repository and add it as a remote instead, but that is more cumbersome.
+
+However the pre-commit hook messes things up when it is being run inside the linked worktree as well. It really should only run in the main worktree.
+
+Could you please merge the [worktree](https://github.com/hlovdal/etkeeper/compare/master...worktree) branch which contains one commit that adds a check to avoid running the pre-commit hook in linked worktrees?

diff --git a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__/comment_1_f4d51ea1f265f09ebbc37ef9d3242be1._comment b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__/comment_1_f4d51ea1f265f09ebbc37ef9d3242be1._comment
new file mode 100644
index 0000000..1b7f017
--- /dev/null
+++ b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__/comment_1_f4d51ea1f265f09ebbc37ef9d3242be1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="hlovdal"
+ nickname="kode"
+ avatar="http://cdn.libravatar.org/avatar/e513ee57b6b0d2c0ae8dfa4b9e85f566"
+ subject="This should not be necessary"
+ date="2022-11-27T17:50:02Z"
+ content="""
+Unless you have a super constrained environment like [openwrt](https://openwrt.org/) then disk usage of `/etc/.git` is completely ignorable (and even so, my openwrt router only uses 2.1Mb for `/etc/.git`, initial commit 2016). I checked all my servers and desktops and the largest was 196Mb on a machine that used to be my main desktop with the repository started in 2017.
+"""]]

diff --git a/doc/todo/metadata_ignore_filters_do_not_work/comment_5_e43de8fe580d3f6884cc7b94c52e0a5b._comment b/doc/todo/metadata_ignore_filters_do_not_work/comment_5_e43de8fe580d3f6884cc7b94c52e0a5b._comment
new file mode 100644
index 0000000..2283e67
--- /dev/null
+++ b/doc/todo/metadata_ignore_filters_do_not_work/comment_5_e43de8fe580d3f6884cc7b94c52e0a5b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b"
+ subject="comment 5"
+ date="2022-11-23T16:33:06Z"
+ content="""
+argh, i meant [[todo/optimize_mode_metadata:_ignore_defaults]]...
+"""]]

diff --git a/doc/todo/metadata_ignore_filters_do_not_work/comment_4_dc188a789e1b40158b14a88d7d088ee2._comment b/doc/todo/metadata_ignore_filters_do_not_work/comment_4_dc188a789e1b40158b14a88d7d088ee2._comment
new file mode 100644
index 0000000..c36f99b
--- /dev/null
+++ b/doc/todo/metadata_ignore_filters_do_not_work/comment_4_dc188a789e1b40158b14a88d7d088ee2._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b"
+ subject="some examples"
+ date="2022-11-23T16:32:38Z"
+ content="""
+here's an example, from my workstation, which has a similar configuration to the server i was working on for this:
+
+    root@curie:/etc# grep puppet/code/production .gitignore .etckeeper 
+    .gitignore:puppet/code/production
+    .etckeeper:mkdir -p './puppet/code/production'
+    .etckeeper:maybe chown 'puppet' 'puppet/code/production'
+    .etckeeper:maybe chgrp 'puppet' 'puppet/code/production'
+    .etckeeper:maybe chmod 0750 'puppet/code/production'
+    root@curie:/etc# ls -al puppet/code/production/
+    total 18
+    drwxr-x--- 2 puppet puppet 2 30 jun  2020 .
+    drwxr-xr-x 3 root   root   3 30 jun  2020 ..
+
+here you see the empty directory is managed in .etckeeper even though it's ignored.
+
+i thought i provided clearer examples of this in the original article, but i guess it wasn't very explicit... here's an example:
+
+right now, if i revert the changes I made to `etckeeper/pre-commit.d/30store-metadata`, and run the hook:
+
+    VCS=git /etc/etckeeper/pre-commit.d/30store-metadata
+
+... i get this:
+
+    root@marcos:/etc# grep puppet/code/production .gitignore 
+    puppet/code/production
+    root@marcos:/etc# grep -c puppet/code/production .etckeeper 
+    87
+
+it's mostly empty directories, but there's also other stuff:
+
+    root@marcos:/etc# grep puppet/code/production .etckeeper | head -3
+    mkdir -p './puppet/code/production/.g10k/CraigWatson1987-transmission-2.2.1/spec/fixtures'
+    mkdir -p './puppet/code/production/.g10k/duritong-sysctl-0.0.12/spec/fixtures/manifests'
+    mkdir -p './puppet/code/production/.g10k/duritong-sysctl-0.0.12/spec/fixtures/modules/sysctl'
+    root@marcos:/etc# grep puppet/code/production .etckeeper | tail -3
+    mkdir -p './puppet/code/production/modules/inifile/locales/ja'
+    maybe chown 'anarcat' 'puppet/code/production'
+    maybe chmod 0755 'puppet/code/production'
+
+with the patch, it looks like this instead:
+
+    root@marcos:/etc# grep puppet/code/production .gitignore 
+    puppet/code/production
+    root@marcos:/etc# grep -c puppet/code/production .etckeeper 
+    0
+
+the patch proposed here, together with the one on [[todo/metadata_ignore_filters_do_not_work]] improve etckeeper performance tremendously in my case.
+"""]]

diff --git a/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__/comment_2_67b06a471f9021ec7e4d41cbaeb8b5bd._comment b/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__/comment_2_67b06a471f9021ec7e4d41cbaeb8b5bd._comment
new file mode 100644
index 0000000..b5428e7
--- /dev/null
+++ b/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__/comment_2_67b06a471f9021ec7e4d41cbaeb8b5bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jerrythepineapple"
+ avatar="http://cdn.libravatar.org/avatar/d152617d7827ea33fe921456f23a7672"
+ subject="comment 2"
+ date="2022-11-17T22:48:28Z"
+ content="""
+Thanks!!
+"""]]

diff --git a/doc/forum/How_to_submit_pull_requests__63__/comment_1_a1ef90ca5f66af6c35ea66b6c520ddd5._comment b/doc/forum/How_to_submit_pull_requests__63__/comment_1_a1ef90ca5f66af6c35ea66b6c520ddd5._comment
new file mode 100644
index 0000000..366a966
--- /dev/null
+++ b/doc/forum/How_to_submit_pull_requests__63__/comment_1_a1ef90ca5f66af6c35ea66b6c520ddd5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-16T20:47:32Z"
+ content="""
+Just go to [[todo]] and make a post there, and include the url of the git
+repository and branch to pull.
+"""]]

diff --git a/doc/todo/metadata_ignore_filters_do_not_work/comment_3_eff7bec1a6b87cc6c2546d181ce8296e._comment b/doc/todo/metadata_ignore_filters_do_not_work/comment_3_eff7bec1a6b87cc6c2546d181ce8296e._comment
new file mode 100644
index 0000000..77b8896
--- /dev/null
+++ b/doc/todo/metadata_ignore_filters_do_not_work/comment_3_eff7bec1a6b87cc6c2546d181ce8296e._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-11-16T17:15:50Z"
+ content="""
+> But why do we list _all_ the ignored files in the metadata store?
+
+It doesn't. This code is what filters those ignored files out of the ones
+that are included. It's easy to show it works:
+
+	root@darkstar:~>grep mtab /etc/.gitignore
+	mtab
+	mtab.fuselock
+	root@darkstar:~>ls /etc/mtab
+	/etc/mtab@
+	root@darkstar:~>grep mtab /etc/.etckeeper
+	- exit 1
+	root@darkstar:~>grep adjtime /etc/.gitignore 
+	adjtime
+	root@darkstar:~>ls /etc/adjtime 
+	/etc/adjtime
+	root@darkstar:~>grep adjtime /etc/.etckeeper 
+	- exit 1
+
+You have not yet given an example of it not working.
+"""]]

diff --git a/doc/forum/How_to_submit_pull_requests__63__.mdwn b/doc/forum/How_to_submit_pull_requests__63__.mdwn
new file mode 100644
index 0000000..44d5330
--- /dev/null
+++ b/doc/forum/How_to_submit_pull_requests__63__.mdwn
@@ -0,0 +1 @@
+I have a few improvements that I'd like to submit, do you accept pull requests?

diff --git a/doc/todo/optimize_mode_metadata:_ignore_defaults/comment_2_fb6294e6d3d04eb26609aca0163d0720._comment b/doc/todo/optimize_mode_metadata:_ignore_defaults/comment_2_fb6294e6d3d04eb26609aca0163d0720._comment
new file mode 100644
index 0000000..90513a0
--- /dev/null
+++ b/doc/todo/optimize_mode_metadata:_ignore_defaults/comment_2_fb6294e6d3d04eb26609aca0163d0720._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b"
+ subject="comment 2"
+ date="2022-11-15T17:50:17Z"
+ content="""
+sure, parsing umask is a possible improvement to this patch.
+"""]]

diff --git a/doc/todo/metadata_ignore_filters_do_not_work/comment_2_23349351fd7f424bfd3073136a6f606c._comment b/doc/todo/metadata_ignore_filters_do_not_work/comment_2_23349351fd7f424bfd3073136a6f606c._comment
new file mode 100644
index 0000000..027762a
--- /dev/null
+++ b/doc/todo/metadata_ignore_filters_do_not_work/comment_2_23349351fd7f424bfd3073136a6f606c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b"
+ subject="comment 2"
+ date="2022-11-15T17:49:48Z"
+ content="""
+> You have misunderstood (and oddly, misquoted) the code.
+>
+> 30store-metadata already uses git ls-files -oi --exclude-standard to list gitignored files. The use of grep is only to search through the resulting list of ignored files, to find an exact match for a filename.. That is indeed inefficient when there are a lot of ignored files. But it matches ignored files correctly.
+
+But why do we list *all* the ignored files in the metadata store? Shouldn't we store data only about files tracked with git?
+
+Maybe you are correct and I do not understand the purpose of this code, I thought the point of the metadata store was to restore modes when checking out files, and therefore that adding ignored files in there was not necessary.
+
+> (30store-metadata does grep .darcsignore, I don't know if that is a good idea.)
+
+that, i cannot say. i haven't used darcs in ages.
+"""]]

diff --git a/doc/forum/Does_not_create_config/comment_1_295ecd7681224829e833536203269129._comment b/doc/forum/Does_not_create_config/comment_1_295ecd7681224829e833536203269129._comment
deleted file mode 100644
index 6141109..0000000
--- a/doc/forum/Does_not_create_config/comment_1_295ecd7681224829e833536203269129._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!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/todo/optimize_mode_metadata:_ignore_defaults/comment_1_bd12401aec0d25d31e2cb260389cb98e._comment b/doc/todo/optimize_mode_metadata:_ignore_defaults/comment_1_bd12401aec0d25d31e2cb260389cb98e._comment
new file mode 100644
index 0000000..cdd42e0
--- /dev/null
+++ b/doc/todo/optimize_mode_metadata:_ignore_defaults/comment_1_bd12401aec0d25d31e2cb260389cb98e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-08T18:49:10Z"
+ content="""
+You are assuming that root has a umask of 022. With other umasks, git uses
+other modes.
+"""]]

diff --git a/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
index 6513b6c..8a675da 100644
--- a/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
+++ b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
@@ -30,4 +30,22 @@ root@marcos:/etc# git diff --cached --stat
 
 yes, you read that right, that's 10 *thousand* files cleaned up. and yes, it seems like i have over 20,000 files in /etc. yikes. (it's mostly because this is a puppet server and there's lots of git repos under there, and cache files. and yes, those are in the .gitignore and shouldn't even be in the `.etckeeper` file in the first place, but that's a different story, see [[todo/metadata_ignore_filters_do_not_work]].
 
+before this and the git ignore patch:
+
+[[!format txt """
+root@marcos:/etc# VCS=git time sh  /home/anarcat/src/etckeeper/pre-commit.d/30store-metadata
+0.22user 0.13system 0:00.34elapsed 104%CPU (0avgtext+0avgdata 11500maxresident)k
+0inputs+12088outputs (0major+4497minor)pagefaults 0swaps
+"""]]
+
+after:
+
+[[!format txt """
+root@marcos:/etc# VCS=git  time sh /etc/etckeeper/pre-commit.d/30store-metadata
+0.07user 0.02system 0:00.09elapsed 106%CPU (0avgtext+0avgdata 7748maxresident)k
+0inputs+2080outputs (0major+3287minor)pagefaults 0swaps
+"""]]
+
+it doesn't look like much, but that's a 10-fold improvement. and it doesn't count the time it takes to actually do the commit, which I haven't benchmarked, but it takes a few *seconds* to commit before the change, and a few miliseconds after.
+
 so anyways, i figured that would be a worthwhile optimisation! :) --[[anarcat]]

diff --git a/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
index 81bd81c..6513b6c 100644
--- a/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
+++ b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
@@ -18,7 +18,7 @@ modified   pre-commit.d/30store-metadata
 
 """]]
 
-See also [this commit](https://salsa.debian.org/debian/etckeeper/-/commit/73fccbde9c30156209362d74811e04dd12de9106) which is the current HEAD of [my optimize-default-metadata branch](https://salsa.debian.org/debian/etckeeper/-/tree/optimize-default-metadata).
+See also [this commit](https://salsa.debian.org/debian/etckeeper/-/commit/73fccbde9c30156209362d74811e04dd12de9106) which is the current HEAD of [my optimize-default-metadata branch](https://salsa.debian.org/debian/etckeeper/-/commits/optimize-default-metadata).
 
 In my messy home server, this gives me that resulting diff:
 

diff --git a/doc/todo/metadata_ignore_filters_do_not_work.mdwn b/doc/todo/metadata_ignore_filters_do_not_work.mdwn
index 0daf815..f884784 100644
--- a/doc/todo/metadata_ignore_filters_do_not_work.mdwn
+++ b/doc/todo/metadata_ignore_filters_do_not_work.mdwn
@@ -27,7 +27,7 @@ I think the pseudocode then would be something like, for the git case:
 
 -- [[anarcat]]
 
-Update: and I think the patch is [something like this](https://salsa.debian.org/debian/etckeeper/-/commit/0a4305886c6e9501eec223880fa9ae8776b4947e). it doesn't *quite* work the way I expected, unfortunately. a few examples:
+Update: and I think the patch is [something like this](https://salsa.debian.org/debian/etckeeper/-/commit/0a4305886c6e9501eec223880fa9ae8776b4947e) (see [branch](https://salsa.debian.org/debian/etckeeper/-/commits/new-git-ignores) for latest. it doesn't *quite* work the way I expected, unfortunately. a few examples:
 
 [[!format diff """
 diff --git a/.etckeeper b/.etckeeper

diff --git a/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
index a87c714..81bd81c 100644
--- a/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
+++ b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
@@ -18,6 +18,8 @@ modified   pre-commit.d/30store-metadata
 
 """]]
 
+See also [this commit](https://salsa.debian.org/debian/etckeeper/-/commit/73fccbde9c30156209362d74811e04dd12de9106) which is the current HEAD of [my optimize-default-metadata branch](https://salsa.debian.org/debian/etckeeper/-/tree/optimize-default-metadata).
+
 In my messy home server, this gives me that resulting diff:
 
 [[!format txt """

diff --git a/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
new file mode 100644
index 0000000..a87c714
--- /dev/null
+++ b/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn
@@ -0,0 +1,31 @@
+here's another idea: why do we store metadata for files that have "default" modes (as understood by git) like `0755` (for directories) or `0644` (for files)? This seems like a huge waste of time and something that grows the `.etckeeper` metadata file needlessly.
+
+I believe the following patch would improve things quite a bit:
+
+[[!format diff """
+modified   pre-commit.d/30store-metadata
+@@ -92,7 +92,9 @@ maybe_chmod_chown() {
+ 			if ($gid != $)) {
+ 				printf "maybe chgrp $q%s$q %s\n", gidname($gid), $_;
+ 			}
+-			printf "maybe chmod %04o %s\n", $mode & 07777, $_;
++			if ($mode != 0100644 and $mode != 040755) {
++				printf "maybe chmod %04o %s\n", $mode & 07777, $_;
++			}
+ 		'
+ 		return $?
+ 	else
+
+"""]]
+
+In my messy home server, this gives me that resulting diff:
+
+[[!format txt """
+root@marcos:/etc# git diff --cached --stat
+ .etckeeper | 10231 --------------------------------------------------------------------------------------------------------------------------------------------------
+ 1 file changed, 10231 deletions(-)
+"""]]
+
+yes, you read that right, that's 10 *thousand* files cleaned up. and yes, it seems like i have over 20,000 files in /etc. yikes. (it's mostly because this is a puppet server and there's lots of git repos under there, and cache files. and yes, those are in the .gitignore and shouldn't even be in the `.etckeeper` file in the first place, but that's a different story, see [[todo/metadata_ignore_filters_do_not_work]].
+
+so anyways, i figured that would be a worthwhile optimisation! :) --[[anarcat]]

diff --git a/doc/todo/metadata_ignore_filters_do_not_work/comment_1_a0a00282ce442b3b485d0c3b6f1a8b32._comment b/doc/todo/metadata_ignore_filters_do_not_work/comment_1_a0a00282ce442b3b485d0c3b6f1a8b32._comment
new file mode 100644
index 0000000..062d043
--- /dev/null
+++ b/doc/todo/metadata_ignore_filters_do_not_work/comment_1_a0a00282ce442b3b485d0c3b6f1a8b32._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-08T18:11:53Z"
+ content="""
+You have misunderstood (and oddly, misquoted) the code.
+
+30store-metadata already uses `git ls-files -oi --exclude-standard` to list
+gitignored files. The use of grep is only to search through the resulting
+list of ignored files, to find an exact match for a filename.. That is
+indeed inefficient when there are a lot of ignored files. But it matches
+ignored files correctly.
+
+(30store-metadata does grep .darcsignore, I don't know if that is a good
+idea.)
+"""]]

diff --git a/doc/todo/metadata_ignore_filters_do_not_work.mdwn b/doc/todo/metadata_ignore_filters_do_not_work.mdwn
index ac88bdc..0daf815 100644
--- a/doc/todo/metadata_ignore_filters_do_not_work.mdwn
+++ b/doc/todo/metadata_ignore_filters_do_not_work.mdwn
@@ -26,3 +26,36 @@ I think the pseudocode then would be something like, for the git case:
 (Also, I don't think that the `maybe_chmod_chown` script should systematically change the mode on files, but that's a different story (and optimization)...)
 
 -- [[anarcat]]
+
+Update: and I think the patch is [something like this](https://salsa.debian.org/debian/etckeeper/-/commit/0a4305886c6e9501eec223880fa9ae8776b4947e). it doesn't *quite* work the way I expected, unfortunately. a few examples:
+
+[[!format diff """
+diff --git a/.etckeeper b/.etckeeper
+index 71fb3188..8b34a087 100755
+--- a/.etckeeper
++++ b/.etckeeper
+@@ -3,34 +3,28 @@
+ mkdir -p './ImageMagick'
+ mkdir -p './X11/xkb'
+ mkdir -p './X11/xorg.conf.d'
+-mkdir -p './apm/event.d'
+-mkdir -p './apm/scripts.d'
++mkdir -p './apm'
+[...]
+"""]]
+
+in the above example, you see that `apm` is correctly added but not the underlying `events.d` and `scripts.d`...
+
+it *does* correctly follow ignores for most stuff however, which is an improvement. I did have to bend over backwards to remove symlinks from the listing, with that ungodly `sed`. and, in general, we have quoting problems here because we pipe filenames that might have newlines in them... thankfully, we might consider `/etc` trusted, but that's something that makes me uncomfortable about this whole thing in the first place...
+
+here at least, a bunch of stuff is cleaned up:
+
+[[!format txt """
+root@marcos:/etc# git diff --cached --stat
+ .etckeeper | 636 ++++------------------------------------------------------------------------------------------------------------------------------------------------
+ 1 file changed, 17 insertions(+), 619 deletions(-)
+root@marcos:/etc# wc -l .etckeeper
+7419 .etckeeper
+"""]]
+
+Anyways, let me know what you think. The main tradeoff here is that we lose empty subdirectories, which maybe is a big deal, but for my use cases, I don't expect etckeeper to recover everything like this, that's what backups are for. ;)

diff --git a/doc/todo/Do_not_recreate_ignored_empty_directory/comment_1_3214141a915a102378fc65084cae597a._comment b/doc/todo/Do_not_recreate_ignored_empty_directory/comment_1_3214141a915a102378fc65084cae597a._comment
new file mode 100644
index 0000000..cd3ce18
--- /dev/null
+++ b/doc/todo/Do_not_recreate_ignored_empty_directory/comment_1_3214141a915a102378fc65084cae597a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b"
+ subject="comment 1"
+ date="2022-11-08T17:27:31Z"
+ content="""
+i'm not sure that's the right way. i think you're right in that `grep -x` doesn't do the right thing, but I'm not sure I understand what you're trying to do with that extra `sed 's-^///--'` pattern there...
+
+I have proposed another solution which you might be interested in, in [[todo/metadata_ignore_filters_do_not_work]], which is basically to stop trying to reimplement git-ignore ourselves...
+"""]]

diff --git a/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/comment_3_f3618a15792640feef3f055ac108e940._comment b/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/comment_3_f3618a15792640feef3f055ac108e940._comment
new file mode 100644
index 0000000..faaaf48
--- /dev/null
+++ b/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/comment_3_f3618a15792640feef3f055ac108e940._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b"
+ subject="comment 3"
+ date="2022-11-08T17:25:58Z"
+ content="""
+i think the proper solution here is to stop trying to replace gitignore with our own implementation and defer everything to `git-ls-files`. i lay out that idea in [[todo/metadata_ignore_filters_do_not_work]] and would very much welcome feedback on that.
+"""]]

diff --git a/doc/todo/metadata_ignore_filters_do_not_work.mdwn b/doc/todo/metadata_ignore_filters_do_not_work.mdwn
new file mode 100644
index 0000000..ac88bdc
--- /dev/null
+++ b/doc/todo/metadata_ignore_filters_do_not_work.mdwn
@@ -0,0 +1,28 @@
+I'm seeing numerous performance problems with etckeeper on my servers. It generally happens when there is a git repository underneath `/etc` or some other thing that generates lots of small files. Typically, what I try next is to make git ignore those files, which works for the git side of things, but not for the etckeeper side of things, as all those files still get listed (and parsed) by etckeeper's `.etckeeper` metadata file.
+
+The problem here is the metadata "ignore" filter doesn't really work. We can see this in multiple different bug reports here, like [[todo/etkeeper_warning_about_hardlinks_doesn__39__t_exclude_ignored_files]], [[todo/Do_not_recreate_ignored_empty_directory]], or [[todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/]]. I think the approach taken to solve this problem is incorrect, which is why I am opening this issue to regroup all of them in one single place.
+
+From what I can tell, the `30store-metadata` script tries to ignore files ignored by git. But it tries to do that using `grep`, and git ignore files are not `grep` patterns at all. In fact, they're not even regular expressions, they are like glob patterns, but with many different exceptions (like `!` to negate a pattern, for example). I do not think there is a command that can faithfully reproduce this outside of git itself.
+
+Right now, we basically do this:
+
+ 1. list all empty directories, and add them to the metadata, regardless of gitignore (which is [[todo/Do_not_recreate_ignored_empty_directory]])
+ 2. then list all files and directories (empty or not), try to filter out ignored files, and try to ignore normal modes, which means:
+    1. `find $NOVCS \( -type f -or -type d \)` (basically skips `.git` and friends)
+    2. `sed 's/^\.\///' | grep -xFvf $(git ls-files -oi --exclude-standard; git ls-files -oi --exclude-standard --directory | sort -u)`
+    3. some inline perl script which actually systematically chmods all files, and optionally changes the owner and group if they are not the EUID/EGID
+
+Now, the problem that concerns us here is mostly in step 2.2 above. That `grep` command is bad for many reasons, but the first of which is `-x`: that will do a full match on the entire line so if you have, say, `puppet` in your `.gitignore` that will match the `puppet` directory, but nothing *underneath*, which is not how gitignore files work *at all*.
+
+I think the proper way to do this is to actually start from files git actually tracks, since in that step, we're trying to keep track of modes and owners of actual files managed by git. It seems to me much better to make git list the files, then process *that*, than try to reimplement git-ignore outside of git.
+
+I think the pseudocode then would be something like, for the git case:
+
+ 1. `git ls-files | sort -u | maybe_chmod_chown`
+ 2. `git ls-files --others --exclude-standard --directory | sed -e "s/^/mkdir -p /"`
+
+... and that's it! The trick here is we separate the normal file tracking (first step) from the empty directory listing (second step). I haven't actually tested this because I'm out of battery in that third yak razor, but I wanted to brainstorm this here first to see if we could somehow make sense of this.
+
+(Also, I don't think that the `maybe_chmod_chown` script should systematically change the mode on files, but that's a different story (and optimization)...)
+
+-- [[anarcat]]

diff --git a/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__/comment_1_33806aefc8706e6db0afec2a9672f3f0._comment b/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__/comment_1_33806aefc8706e6db0afec2a9672f3f0._comment
new file mode 100644
index 0000000..3a573d5
--- /dev/null
+++ b/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__/comment_1_33806aefc8706e6db0afec2a9672f3f0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-10-04T16:37:11Z"
+ content="""
+See [[todo]].
+"""]]

diff --git a/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__.mdwn b/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__.mdwn
new file mode 100644
index 0000000..62b81e9
--- /dev/null
+++ b/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__.mdwn
@@ -0,0 +1 @@
+Hi, I'm having trouble finding the bug tracker for etckeeper is there actually one ? Thanks.

diff --git a/doc/news/version_1.18.13.mdwn b/doc/news/version_1.18.13.mdwn
deleted file mode 100644
index fe8d5a8..0000000
--- a/doc/news/version_1.18.13.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-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.18.mdwn b/doc/news/version_1.18.18.mdwn
new file mode 100644
index 0000000..ba1931d
--- /dev/null
+++ b/doc/news/version_1.18.18.mdwn
@@ -0,0 +1,5 @@
+etckeeper 1.18.18 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Replace deprecated egrep with grep -E.
+    Thanks, Sam James
+  * Added support for Void Linux's xbps package manager.
+    Thanks, Zev Weiss."""]]
\ No newline at end of file

diff --git a/doc/todo/regex_in_20-warn-problem-files.mdwn b/doc/todo/regex_in_20-warn-problem-files.mdwn
index b3f5e79..6aa5532 100644
--- a/doc/todo/regex_in_20-warn-problem-files.mdwn
+++ b/doc/todo/regex_in_20-warn-problem-files.mdwn
@@ -1,11 +1,11 @@
     exclude_internal () {
-            egrep -v '(^|/)(.git|.hg|.bzr|_darcs)/'
+            grep -E -v '(^|/)(.git|.hg|.bzr|_darcs)/'
     }
 
 should probably escape the `.`s. 
 
     exclude_internal () {
-            egrep -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
+            grep -E -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
     }
 
 > [[fixed|done]] --[[Joey]]
diff --git a/etckeeper b/etckeeper
index 0085eee..6de4754 100755
--- a/etckeeper
+++ b/etckeeper
@@ -84,7 +84,7 @@ elif [ "$command" = "pre-apt" ]; then
 	command=pre-install
 fi
 
-if echo "$command" | LANG=C egrep -q '[^-a-z_]'; then
+if echo "$command" | LANG=C grep -E -q '[^-a-z_]'; then
 	echo "etckeeper: invalid command $command" >&2
 	exit 1
 fi
@@ -142,7 +142,7 @@ else
 	# fallback if perl isn't present
 	for script in $ETCKEEPER_CONF_DIR/$command.d/*; do
 		if [ ! -d "$script" -a -x "$script" ]; then
-			echo "$script" | egrep -q "/[-a-zA-Z0-9]+$"
+			echo "$script" | grep -E -q "/[-a-zA-Z0-9]+$"
 			[ $? -eq 0 ] && "$script" "$@"
 		fi
 	done
diff --git a/list-installed.d/50list-installed b/list-installed.d/50list-installed
index 3b2ff6f..0551af4 100755
--- a/list-installed.d/50list-installed
+++ b/list-installed.d/50list-installed
@@ -17,7 +17,7 @@ else
 	# format "package version\n" (or something similar).
 	if [ "$LOWLEVEL_PACKAGE_MANAGER" = dpkg ]; then
 		dpkg-query -W -f '${Status}\t${Package} ${Version} ${Architecture}\n' | \
-			egrep '(ok installed|ok config-files)' | cut -f2,3
+			grep -E '(ok installed|ok config-files)' | cut -f2,3
 	elif [ "$LOWLEVEL_PACKAGE_MANAGER" = rpm ]; then
 		rpm -qa --qf "%|epoch?{%{epoch}}:{0}|:%{name}-%{version}-%{release}.%{arch}\n" | sort
 	elif [ "$LOWLEVEL_PACKAGE_MANAGER" = pacman ]; then
diff --git a/post-install.d/50vcs-commit b/post-install.d/50vcs-commit
index e8fa4fc..11657af 100755
--- a/post-install.d/50vcs-commit
+++ b/post-install.d/50vcs-commit
@@ -66,7 +66,7 @@ if etckeeper unclean; then
 			get_changed_packages | sort | uniq > $pl.found-pkgs
 			if [ -s $pl.found-pkgs ]; then
 				sed -i 's/^/^[-+]/;s/$/ /' $pl.found-pkgs
-				etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | egrep '^[-+]' | grep -f $pl.found-pkgs > $pl.found-packages
+				etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' | grep -f $pl.found-pkgs > $pl.found-packages
 				if [ -s $pl.found-packages ]; then
 					echo "Packages with configuration changes:"
 					cat $pl.found-packages || true
@@ -74,7 +74,7 @@ if etckeeper unclean; then
 				fi
 			fi
 			echo "Package changes:"
-			etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | egrep '^[-+]' || true
+			etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' || true
 		) | etckeeper commit --stdin
 	else
 		etckeeper commit "$(printf "$message")"
diff --git a/pre-commit.d/20warn-problem-files b/pre-commit.d/20warn-problem-files
index 6bd5c2b..43320e4 100755
--- a/pre-commit.d/20warn-problem-files
+++ b/pre-commit.d/20warn-problem-files
@@ -2,7 +2,7 @@
 set -e
 
 exclude_internal () {
-	egrep -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
+	grep -E -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
 }
 
 if [ "$VCS" = bzr ] || [ "$VCS" = darcs ]; then

diff --git a/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists/comment_2_d1d40ba983bdf52502c53c13f8f73919._comment b/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists/comment_2_d1d40ba983bdf52502c53c13f8f73919._comment
new file mode 100644
index 0000000..c2d0ebd
--- /dev/null
+++ b/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists/comment_2_d1d40ba983bdf52502c53c13f8f73919._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Abdull"
+ avatar="http://cdn.libravatar.org/avatar/739dfa7b7b4580406c6e45fc8b3e3520"
+ subject="comment 2"
+ date="2022-01-11T11:56:28Z"
+ content="""
+Thank your for the info, I found your mentioned TODO at *[[todo/Give preference to etckeeper.conf over existing repository for defining $VCS]]*.
+
+I was able to accomplish my scenario (one personal git repository with <del>cherry-picked</del> selected configuration files in one repository AND using etckeeper as well) with the following workaround setup:
+
+* Set up my personal git repository at the root filesystem location `/`.
+* Configure etckeeper to use mercurial/hg.
+
+I noticed that (at least in Debian 11.2 bullseye) `apt install etckeeper` automatically runs `etckeeper init`, thereby setting up a **git**-based etckeeper according to the [default `etckeeper.conf` file](https://git.joeyh.name/index.cgi/etckeeper.git/tree/etckeeper.conf?h=debian&id=e2efb7797cfc0a6b366a9db01d37f685ccf04e22) - but I want **hg**. I looked around, but there doesn't currently seem to be a way (e.g. *debconf*) to configure etckeeper at *pre-installation time* to use hg other than [having an appropriate `/etc/etckeeper/etckeeper.conf` file in place before running `apt install etckeeper`](https://git.joeyh.name/index.cgi/etckeeper.git/tree/debian/postinst?h=debian&id=e2efb7797cfc0a6b366a9db01d37f685ccf04e22#n80). Or is there? Thanks for your help!
+"""]]

diff --git a/doc/forum/Ignore_passwd_backup_files/comment_1_e799e0a5f18cdffc52d29d337c401a19._comment b/doc/forum/Ignore_passwd_backup_files/comment_1_e799e0a5f18cdffc52d29d337c401a19._comment
new file mode 100644
index 0000000..9ae9a57
--- /dev/null
+++ b/doc/forum/Ignore_passwd_backup_files/comment_1_e799e0a5f18cdffc52d29d337c401a19._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-09T15:19:03Z"
+ content="""
+These files are unlikely to change without their originals changing too, so
+how is that unncessary churn? (And if they did change without the originals
+changing, that seems like the kind of event it might be useful to have a
+record of.)
+
+And the hash of the files is the same as the hash of a previous
+version of the original, so including them does not even use more disk
+space.
+
+Aside from gratuitous files that do not belong in /etc, etckeeper should
+accurately reflact the actual contents of the directory by default. To do
+otherwise risks being surprising.
+"""]]

diff --git a/doc/forum/Ignore_passwd_backup_files.mdwn b/doc/forum/Ignore_passwd_backup_files.mdwn
new file mode 100644
index 0000000..51c5a0c
--- /dev/null
+++ b/doc/forum/Ignore_passwd_backup_files.mdwn
@@ -0,0 +1,10 @@
+The passwd, shadow and group files have backups that just create unnecessary churn on the repository, since they are already being tracked.
+
+Ignore:
+
+```
+/passwd-
+/shadow-
+/group-
+/gshadow-
+```

diff --git a/doc/news/version_1.18.12.mdwn b/doc/news/version_1.18.12.mdwn
deleted file mode 100644
index c02b04f..0000000
--- a/doc/news/version_1.18.12.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-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.17.mdwn b/doc/news/version_1.18.17.mdwn
new file mode 100644
index 0000000..64d44d3
--- /dev/null
+++ b/doc/news/version_1.18.17.mdwn
@@ -0,0 +1,7 @@
+etckeeper 1.18.17 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Fix committing of files with spaces in name when perl is not available.
+    Thanks, Henrik Riomar
+  * Ignore udev's FHS violating large binary cache file /etc/udev/hwdb.bin
+  * Avoid warning messages from grep about binary files when there are
+    filenames in /etc that do not correspond to the current locale settings.
+    Thanks, thm"""]]
\ No newline at end of file

diff --git a/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists/comment_1_167ca2ab91c1e4b969ba58f532528a82._comment b/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists/comment_1_167ca2ab91c1e4b969ba58f532528a82._comment
new file mode 100644
index 0000000..dcd9639
--- /dev/null
+++ b/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists/comment_1_167ca2ab91c1e4b969ba58f532528a82._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-07T15:09:03Z"
+ content="""
+We can see why right in /usr/bin/etckeeper:
+
+	if [ -d ".git" ]; then
+	        VCS=git
+	elif [ -d ".hg" ]; then
+	        VCS=hg
+	elif [ -d "_darcs" ]; then
+	        VCS=darcs
+	elif [ -d ".bzr" ]; then
+	        VCS=bzr
+	fi
+
+So the VCS config is only used to control what `etckeeper init` does.
+
+See also this todo item about it, with more discussion:
+[[todo/doc/todo/Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS]]
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index baeb2f2..633d448 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -3,6 +3,9 @@ etckeeper (1.18.17) UNRELEASED; urgency=medium
   * Fix committing of files with spaces in name when perl is not available.
     Thanks, Henrik Riomar
   * Ignore udev's FHS violating large binary cache file /etc/udev/hwdb.bin
+  * Avoid warning messages from grep about binary files when there are
+    filenames in /etc that do not correspond to the current locale settings.
+    Thanks, thm
 
  -- Joey Hess <id@joeyh.name>  Sun, 17 Oct 2021 09:45:48 -0400
 
diff --git a/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn b/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn
index 803edc3..bbb78ea 100644
--- a/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn
+++ b/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn
@@ -8,3 +8,5 @@ grep: (Standardeingabe): Übereinstimmungen in Binärdatei
 
 coming from the `grep` in line 25. It can be fixed by either setting
 `LC_CTYPE=C` (maybe generally, in that file), or by adding `-a` to the `grep` call.
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_3_0b32bf35a6ae4117f277bda7f1a60fd4._comment b/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_3_0b32bf35a6ae4117f277bda7f1a60fd4._comment
new file mode 100644
index 0000000..f5dd4ba
--- /dev/null
+++ b/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_3_0b32bf35a6ae4117f277bda7f1a60fd4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-01-07T15:05:15Z"
+ content="""
+Thanks, I understand.
+
+I've applied the `LC_CTYPE` fix.
+"""]]
diff --git a/pre-commit.d/30store-metadata b/pre-commit.d/30store-metadata
index 82eee88..b3722ab 100755
--- a/pre-commit.d/30store-metadata
+++ b/pre-commit.d/30store-metadata
@@ -16,13 +16,13 @@ filter_ignore() {
 		listfile="$( mktemp -t etckeeper-$VCS.XXXXXXXXXX )"
 		case "$VCS" in
 			darcs)
-				grep -v '^[[:space:]]*\(#\|$\)' "$ignorefile" > "$listfile" || true
-				grep -Evf "$listfile"
+				LC_CTYPE=C grep -v '^[[:space:]]*\(#\|$\)' "$ignorefile" > "$listfile" || true
+				LC_CTYPE=C grep -Evf "$listfile"
 				;;
 			git)
 				(git ls-files -oi --exclude-standard; git ls-files -oi --exclude-standard --directory) | sort | uniq > "$listfile" || true
 				if [ -s "$listfile" ]; then
-					sed 's/^\.\///' | grep -xFvf "$listfile"
+					sed 's/^\.\///' | LC_CTYPE=C grep -xFvf "$listfile"
 				else
 					cat -
 				fi

diff --git a/CHANGELOG b/CHANGELOG
index ae686e9..baeb2f2 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,5 +1,7 @@
 etckeeper (1.18.17) UNRELEASED; urgency=medium
 
+  * Fix committing of files with spaces in name when perl is not available.
+    Thanks, Henrik Riomar
   * Ignore udev's FHS violating large binary cache file /etc/udev/hwdb.bin
 
  -- Joey Hess <id@joeyh.name>  Sun, 17 Oct 2021 09:45:48 -0400
diff --git a/doc/forum/etckeeper_without_perl_and_files_with_spaces/comment_1_690145504a22c701f7f0a707526577a6._comment b/doc/forum/etckeeper_without_perl_and_files_with_spaces/comment_1_690145504a22c701f7f0a707526577a6._comment
new file mode 100644
index 0000000..85db236
--- /dev/null
+++ b/doc/forum/etckeeper_without_perl_and_files_with_spaces/comment_1_690145504a22c701f7f0a707526577a6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-07T15:02:29Z"
+ content="""
+I've applied the patch. Thank you.
+"""]]

diff --git a/doc/forum/etckeeper_without_perl_and_files_with_spaces.mdwn b/doc/forum/etckeeper_without_perl_and_files_with_spaces.mdwn
new file mode 100644
index 0000000..bb68873
--- /dev/null
+++ b/doc/forum/etckeeper_without_perl_and_files_with_spaces.mdwn
@@ -0,0 +1,9 @@
+Etckeeper fails to commit files with spaces in the non `Perl` implementation of `maybe_chmod_chown()`
+
+I have prepared a fix for this here:
+ https://gitlab.com/HRio/etckeeper/-/commits/fix-whitespace
+
+Joey can you have a look?
+
+Thanks,
+ Henrik

diff --git a/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists.mdwn b/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists.mdwn
new file mode 100644
index 0000000..94a95ac
--- /dev/null
+++ b/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists.mdwn
@@ -0,0 +1,19 @@
+#Setup
+etckeeper version:
+
+* `etckeeper/stable,stable,now 1.18.16-1 all [residual-config]`
+
+Environment:
+
+* `Linux Debian-1101-bullseye-amd64-base 5.10.0-9-amd64`
+
+Installed via `apt install etckeeper` on _Debian 11 Bullseye_, so using Debian's [https://packages.debian.org/bullseye/etckeeper](https://packages.debian.org/bullseye/etckeeper).
+
+In case only downstream Debian is the culprit, sorry for reporting here and not downstream - but Debian's bugtracker is so awful to use ...
+
+# Issue
+Despite `/etc/etckeeper/etckeeper.conf` being configured with `VCS="hg"`, the moment a git directory `/etc/.git/` (and/or file `/etc/.gitignore`?) exists, _etckeeper_ will use git (and e.g. `.gitignore` instead of `.hgignore`). Maybe this issue is not limited to Mercurial/hg only, but affects any other VCS (mercurial, bazaar, or darcs) as well.
+
+
+# My scenario
+I noticed this issue as I wanted to set up _etckeeper_ with Mercurial while still being able to use my own git-managed `/etc` hierarchy in parallel: use _etckeeper_ to version/backup all `/etc` files and at the same time have an additional git repository for cherry-picked etc files: _etckeeper_ tracks all files including my custom `conf.d/` etc files and package-provided vanilla files; my additional git repository only tracks my custom `conf.d/` etc files. Unfortunately, [it's not possible to have two git repositories in the same directory (here `/etc`) due to a git repository's `.gitignore` location not being configurable](https://stackoverflow.com/a/17313342/923560), hence my unsuccessful workaround with _etckeeper_ to use hg/Mercurial.

diff --git a/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_2_8ddcd82e06ca0a3c835bf122fcfb2be0._comment b/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_2_8ddcd82e06ca0a3c835bf122fcfb2be0._comment
new file mode 100644
index 0000000..e680a9d
--- /dev/null
+++ b/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_2_8ddcd82e06ca0a3c835bf122fcfb2be0._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://thm.id.fedoraproject.org/"
+ nickname="thm"
+ avatar="http://cdn.libravatar.org/avatar/f274b586047bb4a60d0332e647cd1bea"
+ subject="comment 2"
+ date="2022-01-02T16:38:37Z"
+ content="""
+> I guess the idea with setting LC_CTYPE=C is not to force this error message to English, which would not be useful, but because whatever the locale is set to is causing grep to interpret the input as binary.
+
+Exactly.
+
+> Except.. the C locale seems equally likely cause that as whatever locale they are using? Indeed the one user who mentioned their locale was using de_DE.utf8 so why would setting C help at all?
+
+Because, according to the `grep`'s man page: \"In the C or POSIX locale, all characters are encoded as a single byte and every byte is a valid character.\"
+
+> grep is complaining about its stdin, which comes from running a find in /etc, so there must be some particular file whose name causes grep to behave this way. Apparently one that, in a unicode locale, grep thinks is not unicode, but binary.
+
+While I don't know which files caused the issue for the reporters of the two bugs, I was able to reproduce the issue by running `touch  $'\xf6'` in `/etc`, creating a file named 'ö' in a latin-1 locale, but with an invalid name if interpreted as utf-8. (This can also be seen running `find /etc | iconv -f utf8 - -o /dev/null` which yields `iconv: illegal input sequence at position XY`.)
+
+
+"""]]

diff --git a/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_1_0fd1ffa807fe438edee04ca8883f9333._comment b/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_1_0fd1ffa807fe438edee04ca8883f9333._comment
new file mode 100644
index 0000000..0a7668c
--- /dev/null
+++ b/doc/todo/LANG_issue_with_grep_in_store-metadata/comment_1_0fd1ffa807fe438edee04ca8883f9333._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-31T15:37:27Z"
+ content="""
+Using grep -a would be fine, except people do use etckeeper on non-gnu systems
+and I worry about breaking portability.
+
+I guess the idea with setting `LC_CTYPE=C` is not to force this error
+message to English, which would not be useful, but because whatever the
+locale is set to is causing grep to interpret the input as binary. 
+
+Except.. the C locale seems equally likely cause that as whatever
+locale they are using? Indeed the one user who mentioned their locale
+was using `de_DE.utf8` so why would setting C help at all?
+
+grep is complaining about its stdin, which comes from running a find in
+/etc, so there must be some particular file whose name causes grep to
+behave this way. Apparently one that, in a unicode locale, grep thinks
+is not unicode, but binary.
+
+(Also, there was [[!commit 0dd5ff64bf4dba9a2e54c7f29c96998af5dcebce]]
+which also involved setting LANG=C when using grep, in similarly hard to
+understand circumstances.)
+"""]]

diff --git a/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn b/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn
new file mode 100644
index 0000000..803edc3
--- /dev/null
+++ b/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn
@@ -0,0 +1,10 @@
+Two users report issues ([here](https://bugzilla.redhat.com/show_bug.cgi?id=1979456), [here](https://bugzilla.redhat.com/show_bug.cgi?id=2036327)) with `pre-commit.d/30store-metadata` resp. `commit.d/20store-metadata`:
+
+In a German locale, `etckeeper commit 'daily autocommit'` creates messages like this:
+
+```
+grep: (Standardeingabe): Übereinstimmungen in Binärdatei
+```
+
+coming from the `grep` in line 25. It can be fixed by either setting
+`LC_CTYPE=C` (maybe generally, in that file), or by adding `-a` to the `grep` call.

diff --git a/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored/comment_1_6af78141f196ceb20de7eab613726797._comment b/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored/comment_1_6af78141f196ceb20de7eab613726797._comment
new file mode 100644
index 0000000..a0105c3
--- /dev/null
+++ b/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored/comment_1_6af78141f196ceb20de7eab613726797._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-19T19:39:01Z"
+ content="""
+It seems systemd-update-done writes the file
+<https://www.freedesktop.org/software/systemd/man/systemd-update-done.service.html>,
+but on my Debian system that service is not included. It's only needed
+for a factory reset kind of feature, which probably does not make sense to
+include in many linux distributions.
+
+I'm not sure if it necessarily makes sense to avoid it in all cases.
+If systemd is depending on that state for something it might make sense to
+restore it.
+"""]]

diff --git a/doc/forum/etckeeper_for_arbitrary_directories__63__/comment_1_279cbf0d45b2091ea258ddd645240d5c._comment b/doc/forum/etckeeper_for_arbitrary_directories__63__/comment_1_279cbf0d45b2091ea258ddd645240d5c._comment
new file mode 100644
index 0000000..86c338c
--- /dev/null
+++ b/doc/forum/etckeeper_for_arbitrary_directories__63__/comment_1_279cbf0d45b2091ea258ddd645240d5c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-19T19:31:21Z"
+ content="""
+I choose not to grow etckeeper in this direction, because focus is
+important: etckeeper needs to be as good as possible at version controlling
+/etc, even if that means choices that don't make any sense for version
+controlling another directory.
+
+If you're going to version control a whole system, or some
+subset of it, you have a number of hard problems to solve.
+etckeeper solves probably none of them, except for the solution of "let's
+only version control /etc and so those other problems are not our problems".
+
+So it is not a useful starting point to do that, probably. If it somehow
+is a useful starting point to that, forking it would be appropriate.
+"""]]

diff --git a/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored.mdwn b/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored.mdwn
new file mode 100644
index 0000000..e0ac81c
--- /dev/null
+++ b/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored.mdwn
@@ -0,0 +1,5 @@
+systemd updates the /etc/.updated file with new timestamps frequently.
+
+This file should be ignored by etckeeper.
+
+Didn't find where to post bug reports except this forum.

diff --git a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
index fcac7aa..a0c7d76 100644
--- a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
+++ b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
@@ -17,3 +17,38 @@ So, in a nutshell:
 
 Thanks!
 
+---
+# 2021-11-04
+Ok, I'm back, I think I've found a solution:
+
+```
+git checkout master   # To make sure you're where you think you are
+root_commit=$(git rev-list --max-parents=0 HEAD)
+git log --before "2 weeks ago" -1    # See the commit id and check the date is suitable, don't continue until you're happy
+
+git rebase -i $root_commit   # Starts an editor with a list of every commit since the dawn of time, oldest at the top, latest at the bottom
+```
+In the editor, change 'pick' to 'squash' for every commit **except**:
+
+   * the first (it'll generate an error if you try, as there's nothing to squash it into)
+   * the one you found with 'git log', above
+   * and all the commits after that
+
+After that, run `git gc`; it should clear out all the now-unused commits that were squashed.
+
+To emulate weekly/monthly backups, use that `git log --before "X weeks/months ago" -1` command to find the commits, and then leave them as 'pick' (not 'squash') during the rebase!  :-)
+
+Cautions:
+
+* This worked for me, but may not work for you.  (YMMV)
+* Copy /etc to another directory for experimentation.
+* Back up /etc before you do it for real.
+* If you break it, you get to keep both pieces!
+
+Good luck!
+
+References:
+
+* https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
+* https://git-scm.com/docs/git-rebase
+* https://www.cloudbees.com/blog/git-squash-how-to-condense-your-commit-history

diff --git a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
index 70076cd..fcac7aa 100644
--- a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
+++ b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
@@ -4,7 +4,7 @@ I'm implementing etckeeper for all of our servers, but I'm concerned about the "
 
 Google hasn't explicitly said so, but there are hints that rebasing (followed by garbage collection) will let me squash commits and keep the repository from filling up the root partition.
 
-The `git log "@{two weeks ago}"^-` command shows the last commit made just before (or is it after?) that point in time, so that may be useful in the final solution. 
+The command `git log --before 'two weeks ago' -1` shows the last commit made just before that point in time, so that may be useful in the final solution. 
 
 Also, [[this post|Prevent_hook_running_during_rebase]] briefly describes the correct process for rebasing: `clone /etc repo, edit, and force pull the changes`
 

diff --git a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
index 75ea1ca..70076cd 100644
--- a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
+++ b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
@@ -6,6 +6,8 @@ Google hasn't explicitly said so, but there are hints that rebasing (followed by
 
 The `git log "@{two weeks ago}"^-` command shows the last commit made just before (or is it after?) that point in time, so that may be useful in the final solution. 
 
+Also, [[this post|Prevent_hook_running_during_rebase]] briefly describes the correct process for rebasing: `clone /etc repo, edit, and force pull the changes`
+
 So, in a nutshell: 
 
 * How can I squash all commits older than (say) two weeks into a single commit at the root of the /etc repo, leaving younger commits alone?

diff --git a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
index 097897e..75ea1ca 100644
--- a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
+++ b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
@@ -7,6 +7,7 @@ Google hasn't explicitly said so, but there are hints that rebasing (followed by
 The `git log "@{two weeks ago}"^-` command shows the last commit made just before (or is it after?) that point in time, so that may be useful in the final solution. 
 
 So, in a nutshell: 
+
 * How can I squash all commits older than (say) two weeks into a single commit at the root of the /etc repo, leaving younger commits alone?
   - This should nuke all the copies of things that were deleted from /etc more than two weeks ago, yes?
 

diff --git a/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
new file mode 100644
index 0000000..097897e
--- /dev/null
+++ b/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn
@@ -0,0 +1,16 @@
+Hi;
+
+I'm implementing etckeeper for all of our servers, but I'm concerned about the "unlimited growth potential" of the /etc/.git repository.  (Note: I'm not a git expert by any means.)
+
+Google hasn't explicitly said so, but there are hints that rebasing (followed by garbage collection) will let me squash commits and keep the repository from filling up the root partition.
+
+The `git log "@{two weeks ago}"^-` command shows the last commit made just before (or is it after?) that point in time, so that may be useful in the final solution. 
+
+So, in a nutshell: 
+* How can I squash all commits older than (say) two weeks into a single commit at the root of the /etc repo, leaving younger commits alone?
+  - This should nuke all the copies of things that were deleted from /etc more than two weeks ago, yes?
+
+* If I wanted to emulate monthly, weekly and daily backups (with different retention periods) in the etckeeper repository, how could it be done?
+
+Thanks!
+

diff --git a/doc/forum/can_etckeeper_track_selinux_contexts__63__.mdwn b/doc/forum/can_etckeeper_track_selinux_contexts__63__.mdwn
new file mode 100644
index 0000000..adee03c
--- /dev/null
+++ b/doc/forum/can_etckeeper_track_selinux_contexts__63__.mdwn
@@ -0,0 +1 @@
+Would it be possible to extend etckeeper to track SELinux contexts the same way it does user/group ownership and permissions? These are stored in the security.selinux xattr, so seems like some 'setfattr' calls to restore them could easily be part of the /etc/.etckeeper file. Also, etckeeper could set the SELinux context for /etc/.git, the same way it does chmod 700.

diff --git a/doc/forum/etckeeper_for_arbitrary_directories__63__.mdwn b/doc/forum/etckeeper_for_arbitrary_directories__63__.mdwn
new file mode 100644
index 0000000..9605375
--- /dev/null
+++ b/doc/forum/etckeeper_for_arbitrary_directories__63__.mdwn
@@ -0,0 +1,11 @@
+I have some files outside of /etc I want to track (/usr/local/bin/*, /usr/lib/systemd/*, /boot/loader/entries/*). I suppose the `-d` option lets you use repos for arbitrary directories, but I would like to keep everything outside of $HOME in one repo as a opposed to a separate repo for /usr/local/bin, /usr/lib/systemd, etc. as they are all related system files.
+
+[This suggestion](https://serverfault.com/a/858674) suggests a `etckeeper init -d /` will work (and presumably ignore everything but those files in directories above, via gitignore) but when I do that, I run out of disk space (the resulting `/.git` repo is 7.9GB+ until my disk runs out of space. If I do a `git init /` instead, there's no issues. I suppose the issue is `etckeeper init` automatically adds all files to the index, resulting in the repo taking up a large amount of space that is proportional to `/`? 
+
+Is it possible to make `/` a repo ignoring all files except those in the directories above along with etc? Things like `.gitignore` and `showUntrackedFiles = no` cannot be applied when `etckeeper init -d /` cannot set up the repo due to lack of space. 
+
+P.S.
+
+A [workaround](https://serverfault.com/a/293081) is a hook that copies files outside of `/etc` into the `/etc` repo (presumably as a pre-commit hook?) so that they can be tracked. Another hook (assuming it's possible? It wasn't mentioned in that thread but something is needed. Otherwise, a wrapper script) would copy those files back to the appropriate location. This is satisfactory, but duplicate files involved is not ideal.
+
+Any suggestions is much appreciated. etckeeper seems appropriate for my uses because it looks to be a simple git wrapper that preserves metadata (ownership, permissions, etc.) and offers package management integration.

diff --git a/doc/forum/openbsd_find_lacks_-printf.mdwn b/doc/forum/openbsd_find_lacks_-printf.mdwn
new file mode 100644
index 0000000..017da26
--- /dev/null
+++ b/doc/forum/openbsd_find_lacks_-printf.mdwn
@@ -0,0 +1,20 @@
+OpenBSD find does not have `-printf` which is used in `/etc/etckeeper/commit.d/50vcs-commit` to figure out who is running the command:
+
+    # uname -a
+    OpenBSD myhost 6.9 GENERIC.MP#473 amd64
+    # etckeeper commit
+    find: -printf: unknown option
+
+I replaced `USER="$(find "$TTY" -printf "%u")"` with `USER=dunno` as this makes it work.
+
+OpenBSD has perl in its base so:
+
+    perl -MFile::stat -E "my \$st = stat(\"$TTY\"); say( (getpwuid(\$st->uid))[0] )";
+
+or
+
+    perl -MFile::stat -E "my \$st = stat(qq{$TTY}); say( (getpwuid(\$st->uid))[0] )";
+
+would work.
+
+-- cstamas

diff --git a/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn b/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn
index d676d64..3d2de0d 100644
--- a/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn
+++ b/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn
@@ -1,24 +1,24 @@
 Hello,
 
 I am having issues with etckeeper, failing to commit changes:
-Changes not staged for commit:
-  (use "git add <file>..." to update what will be committed)
-  (use "git restore <file>..." to discard changes in working directory)
-  (commit or discard the untracked or modified content in submodules)
-        modified:   letsencrypt/letsencrypt-autoupdater (modified content)
-
-no changes added to commit (use "git add" and/or "git commit -a")
-warning: etckeeper failed to commit changes in /etc using git
-(Reading database ... 206470 files and directories currently installed.)
-Removing knxd-build-deps (0.14.42-1) ...
-On branch master
-Changes not staged for commit:
-  (use "git add <file>..." to update what will be committed)
-  (use "git restore <file>..." to discard changes in working directory)
-  (commit or discard the untracked or modified content in submodules)
-        modified:   letsencrypt/letsencrypt-autoupdater (modified content)
-
-no changes added to commit (use "git add" and/or "git commit -a")
+	Changes not staged for commit:
+	(use "git add <file>..." to update what will be committed)
+	(use "git restore <file>..." to discard changes in working directory)
+	(commit or discard the untracked or modified content in submodules)
+			modified:   letsencrypt/letsencrypt-autoupdater (modified content)
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
+	warning: etckeeper failed to commit changes in /etc using git
+	(Reading database ... 206470 files and directories currently installed.)
+	Removing knxd-build-deps (0.14.42-1) ...
+	On branch master
+	Changes not staged for commit:
+	(use "git add <file>..." to update what will be committed)
+	(use "git restore <file>..." to discard changes in working directory)
+	(commit or discard the untracked or modified content in submodules)
+			modified:   letsencrypt/letsencrypt-autoupdater (modified content)
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 
 I did try a git add letsencrypt/letsencrypt-autoupdater and git commit -a with no effect.

diff --git a/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn b/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn
new file mode 100644
index 0000000..d676d64
--- /dev/null
+++ b/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn
@@ -0,0 +1,29 @@
+Hello,
+
+I am having issues with etckeeper, failing to commit changes:
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+  (commit or discard the untracked or modified content in submodules)
+        modified:   letsencrypt/letsencrypt-autoupdater (modified content)
+
+no changes added to commit (use "git add" and/or "git commit -a")
+warning: etckeeper failed to commit changes in /etc using git
+(Reading database ... 206470 files and directories currently installed.)
+Removing knxd-build-deps (0.14.42-1) ...
+On branch master
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+  (commit or discard the untracked or modified content in submodules)
+        modified:   letsencrypt/letsencrypt-autoupdater (modified content)
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
+I did try a git add letsencrypt/letsencrypt-autoupdater and git commit -a with no effect.
+
+Can you tell me, how to fix this?
+
+Regards,
+Hendrik

diff --git a/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_7_30b13e28d24f3d37e933de8f07e4dd51._comment b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_7_30b13e28d24f3d37e933de8f07e4dd51._comment
new file mode 100644
index 0000000..d2a6c18
--- /dev/null
+++ b/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/comment_7_30b13e28d24f3d37e933de8f07e4dd51._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://thm.id.fedoraproject.org/"
+ nickname="thm"
+ avatar="http://cdn.libravatar.org/avatar/f274b586047bb4a60d0332e647cd1bea"
+ subject="comment 7"
+ date="2021-02-10T16:09:35Z"
+ content="""
+In Fedora, we have that patch for a while now. However recently, someone [stumbled](https://bugzilla.redhat.com/show_bug.cgi?id=1917461) over the issue joey described in his last comment. Seems like there is indeed only a warning and dnf continues instead of cancelling package installation.
+
+The commit message of the [patch](https://github.com/sourcejedi/etckeeper/commit/8266a4fb) reads:
+
+> For the pre-transaction etckeeper run, this message replaces an exception. So we now avoid logging a traceback, which did not appear to add anything useful.  (In my testing, dnf was continued to install after the exception was logged).
+
+hence I suspect, some more investigation has to happen on how to actually cancel the transaction from within a dnf plugin/hook?
+"""]]

diff --git a/doc/todo/Restore_metadata_at_checkout/comment_3_779e72382600a27e71976133fac5dc14._comment b/doc/todo/Restore_metadata_at_checkout/comment_3_779e72382600a27e71976133fac5dc14._comment
new file mode 100644
index 0000000..16a3bd1
--- /dev/null
+++ b/doc/todo/Restore_metadata_at_checkout/comment_3_779e72382600a27e71976133fac5dc14._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="david.allsopp@9d83c1f5c7dd7ff57a593f0ba01d604c4f00ebc1"
+ nickname="david.allsopp"
+ avatar="http://cdn.libravatar.org/avatar/efcf5b162c580a097386b7ff2d905ce8"
+ subject="comment 3"
+ date="2021-01-12T16:08:03Z"
+ content="""
+Couldn't core.sharedRepository (https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresharedRepository) be sensibly used here to ensure that files are checked very restrictively (to be accessible only by root) and then relaxed by the updates in the githook?
+"""]]

diff --git a/doc/news/version_1.18.11.mdwn b/doc/news/version_1.18.11.mdwn
deleted file mode 100644
index 85ef585..0000000
--- a/doc/news/version_1.18.11.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-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.16.mdwn b/doc/news/version_1.18.16.mdwn
new file mode 100644
index 0000000..2c40958
--- /dev/null
+++ b/doc/news/version_1.18.16.mdwn
@@ -0,0 +1,5 @@
+etckeeper 1.18.16 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Improve sorting stability.
+  * Prefer mktemp over tempfile as the latter displays a deprecation
+    warning since debianutils 4.10.
+    Thanks, Luke Mlsna."""]]
\ No newline at end of file

diff --git a/doc/todo/python3_support/comment_3_3ca5e6f481d97b668a12ff754feda861._comment b/doc/todo/python3_support/comment_3_3ca5e6f481d97b668a12ff754feda861._comment
new file mode 100644
index 0000000..1b27f60
--- /dev/null
+++ b/doc/todo/python3_support/comment_3_3ca5e6f481d97b668a12ff754feda861._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-11-23T16:40:33Z"
+ content="""
+I think that, since I've removed the debian directory upstream,
+the only relevant thing would be adding the new etckeeper-brz
+and perhaps dropping etckeeper-bzr. And maybe something about changing the
+PYTHON value in Makefile, but since that also affects etckeeper-dnf,
+it would need to be checked that that at least builds too.
+
+If someone wants to submit that as a git branch, ok.. Untangling it
+from a debian patch that includes other changes, including ones that
+don't actually do anything (http://bugs.debian.org/975562) does not
+appeal to me myself.
+"""]]

diff --git a/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__/comment_1_070706c7c067a87ca3610af59e0ff169._comment b/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__/comment_1_070706c7c067a87ca3610af59e0ff169._comment
new file mode 100644
index 0000000..09d59de
--- /dev/null
+++ b/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__/comment_1_070706c7c067a87ca3610af59e0ff169._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-11-23T16:35:34Z"
+ content="""
+I suggest you talk to the distribution maintainers about the problem,
+since etckeeper is included in centos, this is certianly an integration bug
+there, and one they should be well suited to dealing with. Even if it ought
+to be eventually fixed in etckeeper itself.
+
+(Jimmy Tang wrote the yum integration, but it was so long ago that I doubt
+trying to get in touch with him would be useful.)
+"""]]

diff --git a/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems/comment_1_ff9b3387ee900ebe609ecba89b28e7c8._comment b/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems/comment_1_ff9b3387ee900ebe609ecba89b28e7c8._comment
new file mode 100644
index 0000000..f9ffc0d
--- /dev/null
+++ b/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems/comment_1_ff9b3387ee900ebe609ecba89b28e7c8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-11-23T16:33:13Z"
+ content="""
+I think this is an unusual configuration, and it would be very clunky to
+need to keep track of every file that might need to be ignored for every
+VCS.
+
+Editing the .gitignore seems like the right solution for you.
+"""]]

diff --git a/doc/news/version_1.18.10.mdwn b/doc/news/version_1.18.10.mdwn
deleted file mode 100644
index e949498..0000000
--- a/doc/news/version_1.18.10.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-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.15.mdwn b/doc/news/version_1.18.15.mdwn
new file mode 100644
index 0000000..5431cc9
--- /dev/null
+++ b/doc/news/version_1.18.15.mdwn
@@ -0,0 +1,14 @@
+etckeeper 1.18.15 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * 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.
+  * If gc.auto is not configured, override the default to make it gc
+    ten times more frequently, to avoid wasting space with loose objects.
+  * update-ignore: Preserve permissions from any preexisting VCS ignore file.
+    Thanks, Austin Chu.
+  * Removed the debian directory from the upstream source package as it's
+    not being maintained; see the debian package for an up-to-date one.
+  * debian/changelog moved to CHANGELOG and debian/copyright to COPYRIGHT."""]]
\ No newline at end of file

diff --git a/doc/todo/preserve_permissions_in_update-ignore.mdwn b/doc/todo/preserve_permissions_in_update-ignore.mdwn
index 829b71a..0bd0e5c 100644
--- a/doc/todo/preserve_permissions_in_update-ignore.mdwn
+++ b/doc/todo/preserve_permissions_in_update-ignore.mdwn
@@ -34,3 +34,5 @@ Austin Chu (1):
  update-ignore.d/01update-ignore | 5 +++++
  2 files changed, 7 insertions(+)
 ```
+
+> [[fixed|done]] --[[Joey]]

diff --git a/doc/todo/preserve_permissions_in_update-ignore/comment_1_7b06f2e4211c4631f5fa6f8992ac6723._comment b/doc/todo/preserve_permissions_in_update-ignore/comment_1_7b06f2e4211c4631f5fa6f8992ac6723._comment
new file mode 100644
index 0000000..9e70253
--- /dev/null
+++ b/doc/todo/preserve_permissions_in_update-ignore/comment_1_7b06f2e4211c4631f5fa6f8992ac6723._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-11-23T16:14:15Z"
+ content="""
+Crucially, etckeeper does not write anything sensitive to .gitignore,
+so there's no information exposure risk, except for anything the admin may
+choose to put in it. So it's fine to leave it 0644 by default on new
+installs. Conversely, etckeeper can't easily tell if the admin might have
+put something sensitive into .gitignore, so it should not try to force the
+permissions back to 0644 on existing installs that have inherited the temp
+file permissions.
+
+Ingenious way to preserve the permissions there. I checked and busybox cp
+supports -fp, so it should bee portable enough to not be a problem.
+
+I'm applying this patch.
+"""]]

diff --git a/doc/todo/preserve_permissions_in_update-ignore.mdwn b/doc/todo/preserve_permissions_in_update-ignore.mdwn
new file mode 100644
index 0000000..829b71a
--- /dev/null
+++ b/doc/todo/preserve_permissions_in_update-ignore.mdwn
@@ -0,0 +1,36 @@
+I've recently noticed that update-ignore forces my /etc/.gitignore permissions to be 0600. I've written up [a patch to let it preserve any preexisting VCS ignore file's permissions and ownership](https://gitlab.com/eefi/etckeeper/-/commit/3b824ea5c8218022347a325a20811a84efa6feb7).
+
+The main practical impact of the current state before this patch is that, at least on Debian systems, the second commit into the /etc repo is sullied by an unexpected edit to /etc/.etckeeper updating the permissions for .gitignore from 0644 to 0600. This happens through the following course of events:
+
+1. During initial etckeeper package installation, the postinst runs `etckeeper init`, creating a 0644 .gitignore file, because update-ignore just follows the active umask when creating a brand new VCS ignore file.
+2. This initial `etckeeper init` creates a first commit that includes an .etckeeper that records the 0644 permissions for .gitignore.
+3. Still during this initial etckeeper package installation, the last step of postinst is to run `etckeeper update-ignore`. This causes the permissions on .gitignore to be changed to 0600.
+4. The administrator makes some changes in /etc.
+5. The administrator uses `etckeeper vcs status` (or `git -C /etc status`) to check what she's about to commit. Because .etckeeper usually isn't updated until the pre-commit is run, the pending change to the .gitignore permissions isn't shown.
+6. The administrator commits her changes. The pre-commit hook updates .etckeeper with .gitignore's new permissions, and that change gets silently lumped in with the other changes actually explicitly planned by the administrator.
+
+My patch takes the approach of preserving any special permissions and ownership an administrator might set. An alternative could be to make update-ignore force root:root 0600 always, by making the results from creating a new VCS ignore file match the results when updating an existing VCS ignore file. But either way, I'd propose that update-ignore be made consistent.
+
+The following are details from `git request-pull` for where to get the specific commit I'm requesting get pulled.
+
+```
+The following changes since commit 38d24e461f332ede0dd76d78e63948812ef1b5ab:
+
+   (2020-11-09 09:39:52 +0000)
+
+are available in the Git repository at:
+
+  https://gitlab.com/eefi/etckeeper.git eefi/preserve-perms-in-update-ignore
+
+for you to fetch changes up to 3b824ea5c8218022347a325a20811a84efa6feb7:
+
+  update-ignore: Preserve existing permissions (2020-11-22 16:48:21 -0500)
+
+----------------------------------------------------------------
+Austin Chu (1):
+      update-ignore: Preserve existing permissions
+
+ debian/changelog                | 2 ++
+ update-ignore.d/01update-ignore | 5 +++++
+ 2 files changed, 7 insertions(+)
+```

diff --git a/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems.mdwn b/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems.mdwn
new file mode 100644
index 0000000..ca5b68a
--- /dev/null
+++ b/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems.mdwn
@@ -0,0 +1,10 @@
+I use etc keeper with git, and some etc files are simultaneous manually managed with RCS (mainly historic reasons)
+etckeeper wants to checkin the ,v RCS repository files.
+
+Shouldnt "RCS/*,v" or something be the default in .gitignore
+
+Or more generally, should it ignore repo files for *all* vc systems not just the one its using?
+
+Where would I make this change locally to fix this, so it applies to all directories and version control systems? Right now Ive just amended the git ignore file
+
+