diff --git a/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_3_f16166d7180d8d7020d2477f28c29801._comment b/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_3_f16166d7180d8d7020d2477f28c29801._comment
new file mode 100644
index 0000000..628a479
--- /dev/null
+++ b/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_3_f16166d7180d8d7020d2477f28c29801._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="Dam9k"
+ avatar="http://cdn.libravatar.org/avatar/fb81b13044aedbf11b3e514bde6cfb1a"
+ subject="comment 3"
+ date="2024-12-11T21:11:08Z"
+ content="""
+Here is what I came up with:
+
+```
+diff --git a/etckeeper/post-install.d/50vcs-commit b/etckeeper/post-install.d/50vcs-commit
+index eba0c39..0ea416c 100755
+--- a/etckeeper/post-install.d/50vcs-commit
++++ b/etckeeper/post-install.d/50vcs-commit
+@@ -3,14 +3,16 @@ set -e
+ 
+ pl=\"/var/cache/etckeeper/packagelist\"
+ 
+-# Parent process is etckeeper
+-# (Only procps ps is currently supported, others will fail,
+-# so this may end up empty.)
+-ETCKEEPER_PID=$( ps --no-headers -o ppid \"${PPID}\" 2>/dev/null | sed 's/^ *//' )
+-
+ # Find the parent of etckeeper and get the command line of the process
+-if ! [ -z \"${ETCKEEPER_PID}\" ]; then
+-       ETCKEEPER_PPID=$( ps --no-headers -o ppid \"${ETCKEEPER_PID}\" | sed 's/^ *//' )
++PSTREE=$(pstree -aAcpsT $$)
++ETCKEEPER_PPID=$(echo \"$PSTREE\" | tac | grep -m 1 $HIGHLEVEL_PACKAGE_MANAGER | cut -d, -f2 | cut -d' ' -f1)
++if [ -z \"${ETCKEEPER_PPID}\" ]; then
++       ETCKEEPER_PID=$( ps --no-headers -o ppid \"${PPID}\" 2>/dev/null | sed 's/^ *//' )
++       if [ -n \"${ETCKEEPER_PID}\" ]; then
++               ETCKEEPER_PPID=$( ps --no-headers -o ppid \"${ETCKEEPER_PID}\" | sed 's/^ *//' )
++       fi
++fi
++if [ -n \"${ETCKEEPER_PPID}\" ]; then
+        ETCKEEPER_PARENT_COMMAND_LINE=$( ps --no-headers -o args \"${ETCKEEPER_PPID}\" )
+ fi
+```
+
+Seems to work for me.
+
+What it does is get the process tree of current process, reverse order, grep for HIGHLEVEL_PACKAGE_MANAGER to get the pid of it.
+If that fails it continues with the old method.
+Then it gets the command line of the found process.
+Not sure if dependency on pstree is something that is a problem or not...
+
+"""]]

diff --git a/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_2_7729c47b75d5c34594599f6cccace111._comment b/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_2_7729c47b75d5c34594599f6cccace111._comment
new file mode 100644
index 0000000..b510b3d
--- /dev/null
+++ b/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_2_7729c47b75d5c34594599f6cccace111._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="Dam9k"
+ avatar="http://cdn.libravatar.org/avatar/fb81b13044aedbf11b3e514bde6cfb1a"
+ subject="comment 2"
+ date="2024-12-11T20:20:34Z"
+ content="""
+joey, thanks for the feedback, I understand now why it was implemented that way.
+I was using pacman not pacman-g2.
+For reference here is how a process tree looks like with pacman:
+
+```
+ 131379 pts/2    SN     0:00      \_ /usr/bin/bash
+ 131967 pts/2    SN+    0:00          \_ pacman -R mc
+ 132102 pts/2    SN+    0:00              \_ /bin/sh /usr/bin/etckeeper post-install
+ 132106 pts/2    SN+    0:00                  \_ /bin/sh /etc/etckeeper/post-install.d/50vcs-commit
+```
+
+Perhaps this could be done in a more generic way by traversing the parents until HIGHLEVEL_PACKAGE_MANAGER is found, I'll try to play with that.
+
+"""]]

diff --git a/doc/forum/RFE:_please_add_support_for_DNF_5/comment_1_0ef2192d2bb4942f5c8a97db73c34a23._comment b/doc/forum/RFE:_please_add_support_for_DNF_5/comment_1_0ef2192d2bb4942f5c8a97db73c34a23._comment
new file mode 100644
index 0000000..1bc473d
--- /dev/null
+++ b/doc/forum/RFE:_please_add_support_for_DNF_5/comment_1_0ef2192d2bb4942f5c8a97db73c34a23._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-12-11T18:01:36Z"
+ content="""
+I'm happy to add it once someone develops a patch.
+
+I guess it would make sense to remove the current support for DNF
+from etckeeper eventually?
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index d93ad17..6f2c71e 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,10 @@
+etckeeper (1.18.23) UNRELEASED; urgency=medium
+
+  * Fix determining command line for commit log when using some package
+    managers like pacman and zypper.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 11 Dec 2024 13:46:53 -0400
+
 etckeeper (1.18.22) upstream; urgency=medium
 
   * Add /etc/cups/printers.conf{,.0} to ignore list
diff --git a/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_1_5a9d859c7f0573c9a9d9b11dd43098d2._comment b/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_1_5a9d859c7f0573c9a9d9b11dd43098d2._comment
new file mode 100644
index 0000000..470f10a
--- /dev/null
+++ b/doc/forum/the_default_commit_message_has_the_wrong_process_name/comment_1_5a9d859c7f0573c9a9d9b11dd43098d2._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-12-11T17:09:22Z"
+ content="""
+I took at look at what's happening here. I see this kind of process tree
+when running etckeeper post-install by hand:
+
+	 397908 pts/16   Ss     0:00  |           \_ sudo -H /bin/bash
+	 397909 pts/16   S      0:00  |               \_ /bin/bash
+	 399115 pts/16   S+     0:00  |                   \_ /bin/sh /usr/bin/etckeeper post-install
+	 399121 pts/16   S+     0:00  |                       \_ /bin/sh /etc/etckeeper/post-install.d/50vcs-commit
+
+And `ETCKEEPER_PID` is set to 397909 and `ETCKEEPER_PPID` to 397908.
+Which is indeed kind of wrong in this case. Your patch fixes this.
+
+However, when using `apt-get install` on Debian, the current code actually makes
+it do the right thing, and report eg "committing changes in /etc made by
+"apt-get install foo". In that case, the process tree is like this:
+
+	 400678 pts/18   S+     0:01  |                   \_ apt-get remove --purge docbook-xsl libxml2-utils
+	 400894 pts/18   S+     0:00  |                       \_ apt-get remove --purge docbook-xsl libxml2-utils
+	 400895 pts/18   S+     0:00  |                           \_ sh -c -- if [ -x /usr/bin/etckeeper ]; then etckeeper post-install; fi
+	 400896 pts/18   S+     0:00  |                               \_ /bin/sh /usr/bin/etckeeper post-install
+	 400901 pts/18   S+     0:00  |                                   \_ /bin/sh /etc/etckeeper/post-install.d/50vcs-commit
+
+With your patch it will pick 400895 as `ETCKEEPER_PPID`. Which technically,
+it is. But that is not the command that the user ran, it's a hook script
+that apt is configured to run, in order to run etckeeper post-install.
+
+So in order to apply your change, this change would also be needed:
+
+	diff --git a/apt.conf b/apt.conf
+	index 5e690a2..5d98d43 100644
+	--- a/apt.conf
+	+++ b/apt.conf
+	@@ -1,5 +1,5 @@
+	-DPkg::Pre-Invoke       { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };
+	-DPkg::Post-Invoke      { "if [ -x /usr/bin/etckeeper ]; then etckeeper post-install; fi"; };
+	+DPkg::Pre-Invoke       { "if [ -x /usr/bin/etckeeper ]; then exec etckeeper pre-install; fi"; };
+	+DPkg::Post-Invoke      { "if [ -x /usr/bin/etckeeper ]; then exec etckeeper post-install; fi"; };
+	 
+	-RPM::Pre-Invoke       { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };
+	-RPM::Post-Invoke      { "if [ -x /usr/bin/etckeeper ]; then etckeeper post-install; fi"; };
+	+RPM::Pre-Invoke       { "if [ -x /usr/bin/etckeeper ]; then exec etckeeper pre-install; fi"; };
+	+RPM::Post-Invoke      { "if [ -x /usr/bin/etckeeper ]; then exec etckeeper post-install; fi"; };
+
+But the same kind of change would also need to be made to other
+package managers' hook scripts.
+
+This is making me start to wonder if all this complexity is needed at all.
+There is an alternative message it can used, "committing changes in /etc after $HIGHLEVEL_PACKAGE_MANAGER run"
+which avoids this complexity and should be fine. This business of walking
+the process tree is a fairly recent addition and is buggy, so why do it.
+
+On the third hand, it is pretty nice, when it works, to see the actual
+package manager command line in the commit message.
+
+I guess what we could do is vary how `ETCKEEPER_PPID` is determined based
+on `HIGHLEVEL_PACKAGE_MANAGER`. And only use it for the message when it's a
+package manager we know how to get the pid of. Which right now, for me, is
+only apt..
+
+Were you using pacman, or pacman-g2? I guess pacman since it looks like
+it probably exec's etckeeper without any `sh -c` process.
+"""]]
diff --git a/post-install.d/50vcs-commit b/post-install.d/50vcs-commit
index eba0c39..525bdb0 100755
--- a/post-install.d/50vcs-commit
+++ b/post-install.d/50vcs-commit
@@ -3,15 +3,29 @@ set -e
 
 pl="/var/cache/etckeeper/packagelist"
 
-# Parent process is etckeeper
-# (Only procps ps is currently supported, others will fail,
-# so this may end up empty.)
-ETCKEEPER_PID=$( ps --no-headers -o ppid "${PPID}" 2>/dev/null | sed 's/^ *//' )
+# Find the pid whose parent is the command line that the user ran.
+# Depending on how the highlevel package manager starts etckeeper,
+# this can be either the parent process, or the parent of the parent
+# process.
+case $HIGHLEVEL_PACKAGE_MANAGER in
+	pacman|zypper)
+		ETCKEEPER_PID="${PPID}"
+	;;
+	apt|yum|dnf)
+		# (Only procps ps is currently supported, others will fail,
+		# so this may end up empty.)
+		ETCKEEPER_PID=$( ps --no-headers -o ppid "${PPID}" 2>/dev/null | sed 's/^ *//' )
+	;;
+esac
 
-# Find the parent of etckeeper and get the command line of the process
 if ! [ -z "${ETCKEEPER_PID}" ]; then
-	ETCKEEPER_PPID=$( ps --no-headers -o ppid "${ETCKEEPER_PID}" | sed 's/^ *//' )
-	ETCKEEPER_PARENT_COMMAND_LINE=$( ps --no-headers -o args "${ETCKEEPER_PPID}" )
+	# Find the parent to get the command line.
+	# (Only procps ps is currently supported, others will fail,
+	# so this may end up empty.)
+	ETCKEEPER_PPID=$( ps --no-headers -o ppid "${ETCKEEPER_PID}" 2>/dev/null | sed 's/^ *//' )
+	if ! [ -z "${ETCKEEPER_PPID}" ]; then
+		ETCKEEPER_PARENT_COMMAND_LINE=$( ps --no-headers -o args "${ETCKEEPER_PPID}" )
+	fi
 fi
 
 get_changes () {

diff --git a/doc/forum/the_default_commit_message_has_the_wrong_process_name.mdwn b/doc/forum/the_default_commit_message_has_the_wrong_process_name.mdwn
new file mode 100644
index 0000000..f33f7ac
--- /dev/null
+++ b/doc/forum/the_default_commit_message_has_the_wrong_process_name.mdwn
@@ -0,0 +1,29 @@
+The default commit title when installing new packages is:
+
+```committing changes in /etc made by "/usr/bin/bash"```
+
+Instead of referencing the proper package manager process (pacman in my case)
+This change fixes it:
+
+```
+--- a/etckeeper/post-install.d/50vcs-commit
++++ b/etckeeper/post-install.d/50vcs-commit
+@@ -4,9 +4,7 @@ set -e
+ pl="/var/cache/etckeeper/packagelist"
+ 
+ # Parent process is etckeeper
+-# (Only procps ps is currently supported, others will fail,
+-# so this may end up empty.)
+-ETCKEEPER_PID=$( ps --no-headers -o ppid "${PPID}" 2>/dev/null | sed 's/^ *//' )
++ETCKEEPER_PID=${PPID}
+ 
+ # Find the parent of etckeeper and get the command line of the process
+ if ! [ -z "${ETCKEEPER_PID}" ]; then
+```
+
+So that the commit title is now proper, eg.:
+
+```committing changes in /etc made by "pacman -S minidlna"```
+
+Will you include this fix?
+Or is it expected that I open a pull request? Not sure how it's done on this site as I'm not familiar with it...

diff --git a/doc/forum/Unable_to_update_Ubuntu/comment_1_eaa6f6e597e884692c1f7132e30d44ae._comment b/doc/forum/Unable_to_update_Ubuntu/comment_1_eaa6f6e597e884692c1f7132e30d44ae._comment
new file mode 100644
index 0000000..fc2e432
--- /dev/null
+++ b/doc/forum/Unable_to_update_Ubuntu/comment_1_eaa6f6e597e884692c1f7132e30d44ae._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-12-09T18:14:07Z"
+ content="""
+It appears that somehow the README files have had their execute bits set on
+your system. So you should `chmod -x` them. If Ubuntu is somehow shipping
+the README files with the execute bit set, you should file a bug on
+Ubuntu.
+"""]]

diff --git a/doc/forum/How_to_stop_etckeeper_to_set_permission_0700_on___47__etc__47__.etckeeper/comment_1_fcdd734dcc1709ffba2392e894b3da0d._comment b/doc/forum/How_to_stop_etckeeper_to_set_permission_0700_on___47__etc__47__.etckeeper/comment_1_fcdd734dcc1709ffba2392e894b3da0d._comment
new file mode 100644
index 0000000..1312953
--- /dev/null
+++ b/doc/forum/How_to_stop_etckeeper_to_set_permission_0700_on___47__etc__47__.etckeeper/comment_1_fcdd734dcc1709ffba2392e894b3da0d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-12-09T18:08:30Z"
+ content="""
+You can edit /etc/etckeeper/pre-commit.d/30store-metadata and find in that
+file where it has `chmod 700`. Do note the comment about why it uses that
+permission.
+
+It seems to me that any backup software that is operating on /etc needs to
+be able to read /etc/shadow, and only root and group shadow can. So unless
+your backup program is running as group shadow with some other user, I
+wonder how it can make sense to need to do this.
+"""]]

diff --git a/doc/news/version_1.18.17.mdwn b/doc/news/version_1.18.17.mdwn
deleted file mode 100644
index 64d44d3..0000000
--- a/doc/news/version_1.18.17.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-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/news/version_1.18.22.mdwn b/doc/news/version_1.18.22.mdwn
new file mode 100644
index 0000000..6baf2bd
--- /dev/null
+++ b/doc/news/version_1.18.22.mdwn
@@ -0,0 +1,3 @@
+etckeeper 1.18.22 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Add /etc/cups/printers.conf{,.0} to ignore list
+    Thanks Ben Zanin."""]]
\ No newline at end of file

diff --git a/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn b/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
index faf5462..1b220d4 100644
--- a/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
+++ b/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
@@ -2,10 +2,12 @@ Dear etckeeper developers,
 
 Fedora 41 ships with DNF 5, and CentOS Stream and Red Hat Enterprise Linux 11 will ship with DNF 5 as well in 2027/8
 
-Plugins need to be rewritten in C++ to keep working - including for etckeeper:
+Plugins need to be rewritten to keep working - including for etckeeper:
 
 https://dnf5.readthedocs.io/en/stable/tutorial/plugins/index.html
 
+(Python plugins are also now possible, the documentation is out of date; see e.g. https://github.com/rpm-software-management/dnf5/blob/main/libdnf5-plugins/python_plugins_loader/plugin.py)
+
 Until then, etckeeper "works" in Fedora but requires manually committing; the automatic commit per DNF transaction no longer works.
 
 As reported by a Fedora user: https://bugzilla.redhat.com/show_bug.cgi?id=2326283

diff --git a/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn b/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
index bf7bbc2..faf5462 100644
--- a/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
+++ b/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
@@ -14,4 +14,5 @@ Best regards,
 
 -- 
 Michel Lind
+
 Fedora package maintainer

diff --git a/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn b/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
new file mode 100644
index 0000000..bf7bbc2
--- /dev/null
+++ b/doc/forum/RFE:_please_add_support_for_DNF_5.mdwn
@@ -0,0 +1,17 @@
+Dear etckeeper developers,
+
+Fedora 41 ships with DNF 5, and CentOS Stream and Red Hat Enterprise Linux 11 will ship with DNF 5 as well in 2027/8
+
+Plugins need to be rewritten in C++ to keep working - including for etckeeper:
+
+https://dnf5.readthedocs.io/en/stable/tutorial/plugins/index.html
+
+Until then, etckeeper "works" in Fedora but requires manually committing; the automatic commit per DNF transaction no longer works.
+
+As reported by a Fedora user: https://bugzilla.redhat.com/show_bug.cgi?id=2326283
+
+Best regards,
+
+-- 
+Michel Lind
+Fedora package maintainer

diff --git a/doc/todo/Restore_metadata_at_checkout/comment_4_960e3d70d2057696536d7ff3b8df17fe._comment b/doc/todo/Restore_metadata_at_checkout/comment_4_960e3d70d2057696536d7ff3b8df17fe._comment
new file mode 100644
index 0000000..2cbf080
--- /dev/null
+++ b/doc/todo/Restore_metadata_at_checkout/comment_4_960e3d70d2057696536d7ff3b8df17fe._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Alejandro"
+ avatar="http://cdn.libravatar.org/avatar/cb362008d76dcc1c025d4b4f9226d61c"
+ subject="comment 4"
+ date="2024-10-30T18:23:02Z"
+ content="""
+Hello. I've just asked a question on stackoverflow about the safe way to do checkouts:
+
+https://security.stackexchange.com/questions/279328/etckeeper-check-out-in-a-safe-way
+
+Would this suffice? I mean, would this prevent exposing sensitive data in /etc?
+
+umask 077  
+git checkout april_first_joke_etc  
+etckeeper init  
+umask 022     # or whatever it was before, or just quit current session  
+
+"""]]

diff --git a/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail/comment_2_6bec9ad45450d9ebefd212e05e6868ef._comment b/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail/comment_2_6bec9ad45450d9ebefd212e05e6868ef._comment
new file mode 100644
index 0000000..8646304
--- /dev/null
+++ b/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail/comment_2_6bec9ad45450d9ebefd212e05e6868ef._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="tst"
+ avatar="http://cdn.libravatar.org/avatar/e14c40a1ce6435dfe858dd9286b8b915"
+ subject="comment 2"
+ date="2024-10-15T09:51:57Z"
+ content="""
+The git-gc man pages say
+
+> When common porcelain operations that create objects are run, they will check whether the repository has grown substantially since the last maintenance, and if so run git gc automatically.
+
+So `git` itself runs `git gc` every time `etckeeper` commits anything, unless `gc.auto` is set to `0` in the config.
+
+This behaviour normaly is helpful, but the additional are mails not. Since they are sent by `anacron`, an easy solution is to disable the cron job. You can use the systemd timer instead, but you have to set up extra monitoring if you still want to know if etckeeper's daily commits fail.
+"""]]

diff --git a/doc/todo/Pull_request:_Keep_track_of_FACLs.mdwn b/doc/todo/Pull_request:_Keep_track_of_FACLs.mdwn
new file mode 100644
index 0000000..a61d678
--- /dev/null
+++ b/doc/todo/Pull_request:_Keep_track_of_FACLs.mdwn
@@ -0,0 +1 @@
+It would be nice to keep track of FACLs of the files in /etc.  I believe this is rather easy to do, and have added scripts to `init.d` and `pre-commit.d` that restore and store ACLs, respectively.  Please consider pulling the changes from https://codeberg.org/tdussa/etckeeper (only the latest commit is relevant: https://codeberg.org/tdussa/etckeeper/commit/220cac62d7830cf15f923bfc466642b1ff8326f4).

diff --git a/doc/forum/How_to_stop_etckeeper_to_set_permission_0700_on___47__etc__47__.etckeeper.mdwn b/doc/forum/How_to_stop_etckeeper_to_set_permission_0700_on___47__etc__47__.etckeeper.mdwn
new file mode 100644
index 0000000..207e3eb
--- /dev/null
+++ b/doc/forum/How_to_stop_etckeeper_to_set_permission_0700_on___47__etc__47__.etckeeper.mdwn
@@ -0,0 +1,3 @@
+Etckeeper continuously resets the file permission for `/etc/.etckeeper` back to `0700`. For backup reasons I need it to be group-readable at least, i.e. `0740`. Every time etckeeper resets the file permissions, my nightly backup breaks.
+
+How do I keep etckeeper from resetting the file permissions?

diff --git a/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
index 7381d4c..6b23407 100644
--- a/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
+++ b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
@@ -2,6 +2,6 @@ Please consider adding the following commit from [this branch](https://github.co
 
 ## Don't try to add git-commit hook when in a git worktree
 
-The commit-hook itself already checks for git worktrees and skips any actions which would modify the `.etckeeper` file. This commit adds a similar check to the `etckeeper init` command which skips trying to install the git commit-hook when inside a git worktree. This avoids the following error message (from running `etckeeper init -d` inside a worktree to e.g. fix permissions):
+The commit-hook itself already checks for git worktrees and skips any actions which would modify the `.etckeeper` file. This commit adds a similar check to the `etckeeper init` command which skips trying to install the git commit-hook when inside a git worktree. This avoids the following error message (from running `etckeeper init -d .` inside a worktree to e.g. fix permissions):
 
     /etc/etckeeper/init.d/50vcs-pre-commit-hook: 11: cannot create .git/hooks/pre-commit: Directory nonexistent

diff --git a/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
index 6d81a62..7381d4c 100644
--- a/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
+++ b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
@@ -2,6 +2,6 @@ Please consider adding the following commit from [this branch](https://github.co
 
 ## Don't try to add git-commit hook when in a git worktree
 
-The commit-hook itself already checks for git worktrees and skips any actions which would modify the `.etckeeper` file. This commit adds a similar check to the `etckeeper init` command which skips trying to install the git commit-hook itself when inside a git worktree. This avoids the following error message (from running `etckeeper init -d` inside a worktree to e.g. fix permissions):
+The commit-hook itself already checks for git worktrees and skips any actions which would modify the `.etckeeper` file. This commit adds a similar check to the `etckeeper init` command which skips trying to install the git commit-hook when inside a git worktree. This avoids the following error message (from running `etckeeper init -d` inside a worktree to e.g. fix permissions):
 
     /etc/etckeeper/init.d/50vcs-pre-commit-hook: 11: cannot create .git/hooks/pre-commit: Directory nonexistent

diff --git a/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
index 45ae880..6d81a62 100644
--- a/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
+++ b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
@@ -1,5 +1,7 @@
-Please consider adding the change from this [pull request](https://github.com/ktetzlaff/etckeeper-fork/tree/fix-init-in-worktree):
+Please consider adding the following commit from [this branch](https://github.com/ktetzlaff/etckeeper-fork/tree/fix-init-in-worktree):
 
-The commit-hook itself already checks for git worktrees and skips any actions which would modify the .etckeeper file. This commit adds a similar check to the `etckeeper init` command which skips trying to install the git commit-hook itself when inside a git worktree. This avoids the following error message (from running `etckeeper init -d` inside a worktree to e.g. fix permissions):
+## Don't try to add git-commit hook when in a git worktree
+
+The commit-hook itself already checks for git worktrees and skips any actions which would modify the `.etckeeper` file. This commit adds a similar check to the `etckeeper init` command which skips trying to install the git commit-hook itself when inside a git worktree. This avoids the following error message (from running `etckeeper init -d` inside a worktree to e.g. fix permissions):
 
     /etc/etckeeper/init.d/50vcs-pre-commit-hook: 11: cannot create .git/hooks/pre-commit: Directory nonexistent

diff --git a/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
new file mode 100644
index 0000000..45ae880
--- /dev/null
+++ b/doc/todo/Pull_request:_check_for_git_worktree_before_trying_to_add_pre-commit_hook.mdwn
@@ -0,0 +1,5 @@
+Please consider adding the change from this [pull request](https://github.com/ktetzlaff/etckeeper-fork/tree/fix-init-in-worktree):
+
+The commit-hook itself already checks for git worktrees and skips any actions which would modify the .etckeeper file. This commit adds a similar check to the `etckeeper init` command which skips trying to install the git commit-hook itself when inside a git worktree. This avoids the following error message (from running `etckeeper init -d` inside a worktree to e.g. fix permissions):
+
+    /etc/etckeeper/init.d/50vcs-pre-commit-hook: 11: cannot create .git/hooks/pre-commit: Directory nonexistent

diff --git a/doc/forum/Unable_to_update_Ubuntu.mdwn b/doc/forum/Unable_to_update_Ubuntu.mdwn
new file mode 100644
index 0000000..f43c3c0
--- /dev/null
+++ b/doc/forum/Unable_to_update_Ubuntu.mdwn
@@ -0,0 +1,15 @@
+The operating system fails to make the proper updates:
+
+    /etc/etckeeper/unclean.d/README: 1: Files: not found
+    /etc/etckeeper/unclean.d/README: 2: uncommitted: not found
+    /etc/etckeeper/pre-install.d/README: 1: Files: not found
+    /etc/etckeeper/pre-install.d/README: 2: etc.: not found
+    /etc/etckeeper/pre-install.d/README: 3: uncommitted: not found
+    E: Problem executing scripts DPkg::Pre-Invoke 'if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi'
+    E: Sub-process returned an error code
+
+I have disabled the services *etckeeper.service* and *etckeeper.timer* and tried to uninstall but that error persist.
+
+Can you please assist me to fix the bug?
+
+Thank you in advance.

diff --git a/doc/forum/perl:_warning:_Setting_locale_failed/comment_1_aaa6460af098e4f17d8cf4f24006eb39._comment b/doc/forum/perl:_warning:_Setting_locale_failed/comment_1_aaa6460af098e4f17d8cf4f24006eb39._comment
new file mode 100644
index 0000000..5793177
--- /dev/null
+++ b/doc/forum/perl:_warning:_Setting_locale_failed/comment_1_aaa6460af098e4f17d8cf4f24006eb39._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="weirdhazel"
+ avatar="http://cdn.libravatar.org/avatar/1780f57494741365e3606ee0226a3ef4"
+ subject="comment 1"
+ date="2024-05-09T11:03:13Z"
+ content="""
+I think I figured it out.
+
+This seems to happen because iTerm2 sends the local locale env vars to the remote host
+and LC_CTYPE = \"UTF-8\" is not a valid locale on Linux.
+"""]]

diff --git a/doc/forum/perl:_warning:_Setting_locale_failed.mdwn b/doc/forum/perl:_warning:_Setting_locale_failed.mdwn
new file mode 100644
index 0000000..2e17414
--- /dev/null
+++ b/doc/forum/perl:_warning:_Setting_locale_failed.mdwn
@@ -0,0 +1,62 @@
+Hi,
+
+I'm using macOS (and the iTerm2 terminal emulator) to ssh to a raspberry pi that has Ubuntu 24.04, running the zsh shell.
+
+Whenever I run etckeeper commit (or when it happens implicitly via sudo apt install ...)
+
+I get the following warnings multiple times.
+
+```
+$ sudo etckeeper commit
+perl: warning: Setting locale failed.
+perl: warning: Please check that your locale settings:
+	LANGUAGE = "en_US.UTF-8",
+	LC_ALL = (unset),
+	LC_CTYPE = "UTF-8",
+	LC_COLLATE = "C",
+	LC_TERMINAL = "iTerm2",
+	LANG = "en_US.UTF-8"
+    are supported and installed on your system.
+perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
+perl: warning: Setting locale failed.
+perl: warning: Please check that your locale settings:
+	LANGUAGE = "en_US.UTF-8",
+	LC_ALL = (unset),
+	LC_CTYPE = "UTF-8",
+	LC_COLLATE = "C",
+	LC_TERMINAL = "iTerm2",
+	LANG = "en_US.UTF-8"
+    are supported and installed on your system.
+perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
+[master 82468a9] test 2
+```
+
+My .zshrc exports
+```
+export LC_ALL=en_US.UTF-8
+export LANG=en_US.UTF-8
+export LANGUAGE=en_US.UTF-8
+```
+
+My env contains 
+```
+LC_TERMINAL=iTerm2
+LC_CTYPE=UTF-8
+LC_ALL=en_US.UTF-8
+LANG=en_US.UTF-8
+LANGUAGE=en_US.UTF-8
+```
+
+I noticed that /etc/etckeeper/pre-commit.d/30store-metadata contains the following lines of code.
+
+```
+LC_COLLATE=C
+export LC_COLLATE
+unset LC_ALL
+```
+
+If I comment the code out, the warnings disappears. I assume the statements are needed for a reason though.
+
+I'm not really familiar with locale interactions, so i'm not sure if my config is wrong or it's something that etckeeper doesn't expect.
+
+Would anyone be able to share some advice how I could stop the warnings from happening? Thanks.

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.
+"""]]