Added a comment: comment igendwas
This commit is contained in:
parent
432e7cd9f3
commit
c0b2eb3914
1 changed files with 20 additions and 0 deletions
|
@ -0,0 +1,20 @@
|
|||
[[!comment format=mdwn
|
||||
username="Mowgli"
|
||||
avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
|
||||
subject="comment igendwas"
|
||||
date="2023-06-05T20:33:42Z"
|
||||
content="""
|
||||
> If git-annex metadata contains unicode and you enter a view, git-annex is operating acceptably when it preserves that unicode in the viewed filename.
|
||||
|
||||
But in this case, the metadata does NOT contain unicode/utf-8/whatever exotic charset. It contains ASCII, plain ASCII and git-annex is doing something with it that is not expetable.
|
||||
|
||||
> Maybe git-annex could try to transliterate unicode in viewed filenames in some way to work better non-unicode locales. But the locale can change. And git-annex needs to be able to reverse view filenames back to the filename used on the viewed branch. So it's not practical to vary the view filenames to fit the locale, because that would prevent that reversing from working unless it had a way to determine that locale that was in use when the view was generated.
|
||||
|
||||
It gets even more strange. I tried to rename the files, replacing the strange chars with just a `:`. Git was happy with it, my eyes was happy with it, my filesystem was happy with it but git-annex added now a second tag, additional to the content `:`, that is already there, it created the same key with a value of `ï¹?`. So it is even inconsistent in that case of renaming.
|
||||
|
||||
> git-annex has to replace the / character with something when generating a viewed file from metadata that contains that character. It used to use %, since that at least contains a slash, but I didn't think that was very readable. The unicode slash character it uses is very readable for the vast percentage of users who are not stuck with 1980's era displays.
|
||||
|
||||
Another opportunity is to abort and tell the user that this char is not allowed in current filesystem. Or give the user a opportunity to replace it with his own choice.
|
||||
|
||||
But I did not speak of the slash, I spoke about a double point (`:`). That is a fully legal character in mature filesystems (the most). With that windows filesystems, you mentioned, you have even other troubles that is more important like symlinks...
|
||||
"""]]
|
Loading…
Reference in a new issue