Fix logScanner fails to parse pointer file containing unicode chars

[jochenhz]

Git will quote paths using Unicode characters in git log, but the fileHeaderRegex does not account for optional quotes in the log.

This change fixes the regex to account for quotes due to Unicode characters and improves the tests.
Due to this bug, git lfs prune might accidentally prune recent, unpushed, or stashed files that contain unicode character if there is more than one changed file in the commit.

One might see a git log looking like this, for example (note the quotation marks).

Note: This is rather critical because if the file "Source Assets/Audio/Alltagsger\303\244usche - Kamera - Blitzlicht.mp3" would be unpushed or stashed, prune --force would delete the file as well

lfs-commit-sha: cde89bbb531b285170c0119c34e656141dca269a fba0486e7940971a64f87d8ef8e65fb1be44b2ad

diff --git a/Source Assets/Audio/01 - Am Flughafen - Ankunftsbereich.mp3 b/Source Assets/Audio/01 - Am Flughafen - Ankunftsbereich.mp3
new file mode 100644
index 0000000..8bf5d61
--- /dev/null
+++ b/Source Assets/Audio/01 - Am Flughafen - Ankunftsbereich.mp3       
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:0b21b27eb6f510ef4da2ef3b35c3e394e42e735913fdd2c9bd3dbfde3be19b7b
+size 1535686
diff --git "a/Source Assets/Audio/Alltagsger\303\244usche - Kamera - Blitzlicht.mp3" "b/Source Assets/Audio/Alltagsger\303\244usche - Kamera - Blitzlicht.mp3"
new file mode 100755
index 0000000..63a83b8
--- /dev/null
+++ "b/Source Assets/Audio/Alltagsger\303\244usche - Kamera - Blitzlicht.mp3"   
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:9b265c0416fe1332300bdb08e3d59326b92e948f9a3cab4d4401b11e22100d5b
+size 251836

[bk2204]

This seems fine, but don't we need to handle the octal escapes as well? The example in the PR message shows a couple of octal escapes that we'd probably want to handle in setFilename.

[jochenhz]

This seems fine, but don't we need to handle the octal escapes as well? The example in the PR message shows a couple of octal escapes that we'd probably want to handle in setFilename.

They are already matched by the current regex, see

[bk2204]

They are already matched by the current regex, see

Right, but setFilename checks to see if the file is matched by the filter, and the escaped filename wouldn't necessarily match the filter. If the filter is *ç*.bin and the filename is républiquefrançaise.bin, then the encoded name would be r\303\251publiquefran\303\247aise.bin, and that wouldn't match.

[jochenhz]

They are already matched by the current regex, see

Right, but setFilename checks to see if the file is matched by the filter, and the escaped filename wouldn't necessarily match the filter. If the filter is *ç*.bin and the filename is républiquefrançaise.bin, then the encoded name would be r\303\251publiquefran\303\247aise.bin, and that wouldn't match.

Ah, good catch!
I have pushed a change that converts the incoming name to utf-8 and added some tests for it. Not sure if this is the most elegant solution in golang though.