--- /dev/null
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-12T17:38:43Z"
+ content="""
+git-annex doesn't mess with filename encodings except for the new escaping
+on output. But as far as the path from podcast to disk, it's bytes in and
+bytes out with no concern for encoding. So I don't know how you got these
+two files, but it seems a reasonable hypotehesis that the podcast changed
+the title encoding (and perhaps then changed it back).
+
+It's strange to me that you don't have two separate files visible on disk.
+These are different filenames after all. I wonder if you are using a filesystem
+or OS that treats those as the same filename. That would certianly make
+it harder to list the files some other way and choose one to paste to `git rm`.
+
+Note that git has the same problem of many commands not accepting filenames
+output by other commands.
+
+ joey@darkstar:~/tmp/demo>touch foö
+ joey@darkstar:~/tmp/demo>git add foö
+ joey@darkstar:~/tmp/demo>git status
+ On branch master
+
+ No commits yet
+
+ Changes to be committed:
+ (use "git rm --cached <file>..." to unstage)
+ new file: "fo\303\266"
+ joey@darkstar:~/tmp/demo>git rm --cached "fo\303\266"
+ fatal: pathspec 'fo\303\266' did not match any files
+
+The best workaround I know of is to use `git -c core.quotePath=false`
+to get it to output the actual filenames.
+
+I do think it might be worth adding an option to git-annex to make it
+accept the quotepath formatted filenames. I don't think it can by default.
+"""]]