Recent changes to this wiki:

Added a comment: Use git worktree
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?

Added a comment: This should not be necessary
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.
+"""]]

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

Added a comment: some examples
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.
+"""]]

Added a comment
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!!
+"""]]

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

comment
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?

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

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

removed
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
-"""]]

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

some benchmarks
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]]

link to commit instead of tree, sorry for the noise
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

git branches
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 """

another optimisation
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]]

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

and a patch
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. ;)

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

Added a comment
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]]

comment
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.

add news item for etckeeper 1.18.18
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

Replace obsolete usage of 'egrep' with 'grep -E'
egrep is considered deprecated (and is an alias to grep -E),
so replace it with grep -E.
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

Added a comment
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!
+"""]]

no
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-
+```

add news item for etckeeper 1.18.17
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

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

LC_CTYPE=C when grepping
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
See the todo item for explanation of this.
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

patch applied
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.

Added a comment
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`.)
+
+
+"""]]

comment
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

add news item for etckeeper 1.18.16
diff --git a/doc/news/version_1.18.11.mdwn b/doc/news/version_1.18.11.mdwn
deleted file mode 100644
index 85ef585..0000000
--- a/doc/news/version_1.18.11.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-etckeeper 1.18.11 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Support platforms without a hostname command, fall back to
-     reading /etc/hostname.
-     Thanks, Chris Morgan
-   * commit: Support -mmessage, without a space, since eg git commit
-     can be used that way.
-     Thanks, martin f. krafft
-   * commit: When multiple parameters are given, use them all as the commit
-     message, instead of the old behavior of only using the first parameter and
-     throwing the rest away.
-     Thanks, martin f. krafft"""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.16.mdwn b/doc/news/version_1.18.16.mdwn
new file mode 100644
index 0000000..2c40958
--- /dev/null
+++ b/doc/news/version_1.18.16.mdwn
@@ -0,0 +1,5 @@
+etckeeper 1.18.16 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Improve sorting stability.
+  * Prefer mktemp over tempfile as the latter displays a deprecation
+    warning since debianutils 4.10.
+    Thanks, Luke Mlsna."""]]
\ No newline at end of file

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

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

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

add news item for etckeeper 1.18.15
diff --git a/doc/news/version_1.18.10.mdwn b/doc/news/version_1.18.10.mdwn
deleted file mode 100644
index e949498..0000000
--- a/doc/news/version_1.18.10.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-etckeeper 1.18.10 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Avoid post-install failing when ps is from busybox or another
-     version not supporting procps-specific options.
-   * Use ps --no-headers rather than problimatic -h option."""]]
\ No newline at end of file
diff --git a/doc/news/version_1.18.15.mdwn b/doc/news/version_1.18.15.mdwn
new file mode 100644
index 0000000..5431cc9
--- /dev/null
+++ b/doc/news/version_1.18.15.mdwn
@@ -0,0 +1,14 @@
+etckeeper 1.18.15 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Use "command -v" rather than "which" to detect installed programs,
+    as it is more portable.
+    Thanks, Eli Schwartz.
+  * Improve commit messages generated by package manager changes,
+    listing packages that are responsible for the changed config files.
+    Thanks to emkael for the patch.
+  * If gc.auto is not configured, override the default to make it gc
+    ten times more frequently, to avoid wasting space with loose objects.
+  * update-ignore: Preserve permissions from any preexisting VCS ignore file.
+    Thanks, Austin Chu.
+  * Removed the debian directory from the upstream source package as it's
+    not being maintained; see the debian package for an up-to-date one.
+  * debian/changelog moved to CHANGELOG and debian/copyright to COPYRIGHT."""]]
\ No newline at end of file

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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