+if [ -z "en_GB.UTF-8" ]; then
+       # Default to UTF8 encoding, if unset
+       export LANG=C.UTF-8
+fi

I'm fairly sure it's impossible for this part of the debian patch to do
anything..

#928177. It looks like someone (with a en_GB locale, I should add) hosed
the patch on merge... I committed the patch to git, but it was a merge
of the 1.18.10-1.1 NMU, done by Mattia back in October.

It seems like the fix is to do:

    if [ -z "$LANG" ]; then

instead. The original patch follows.

Thanks for looking at the Debian patchset! :)

From 10d74939aeff32d6638b905ec248ccd6f37fe512 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov <xnox@ubuntu.com>
Date: Mon, 29 Apr 2019 14:11:51 +0100
Subject: [PATCH 2/3] Default to UTF8 encoding, for consistent ordering
---
 debian/changelog              | 1 +
 etckeeper                     | 4 ++++
 pre-commit.d/30store-metadata | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 9457eb2..01aa03a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 etckeeper (1.18.11) UNRELEASED; urgency=medium

   * Add breezy python3 plugin
+  * Default to UTF8 encoding, for consistent ordering

Antoine Beaupré wrote:

That is rather problimatic, bear in mind that etckeeper can run things
like interactive git commits and editors, which could be translated.

Also, LANG only influences sort order when LC_COLLATE is not set.

I guess my commit 4bc7ebe6d29d83df9b86e1be64e696d4d2a70947 upstream
probably fixes whatever this was trying to fix in a better way, although
it's hard to be sure without an explanation of what the actual problem
was.

Why would it matter whether it handles unicode characters or not, if the
point is sort stability?

Those are all good questions, which would be better directed at the
original patch author.

In other words, I have no idea. :)

a.