| Commit message (Collapse) | Author | Age |
... | |
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| |
| |
| |
| |
| | |
This works around a bug in the EvilSplicer; see
http://git-annex.branchable.com/bugs/Bootstrap3_icons_missing_on_Android/
|
|\ \ |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I don't know if this was a bug, but I don't know if it was not a bug
either.
See also,
http://git-annex.branchable.com/bugs/Truncated_file_transferred_via_S3/
where the file is not truncated, but mangled..
|
|/ /
| |
| |
| |
| | |
Char8 often indicates an encoding bug. It didn't here, but I can avoid it
and not worry about it.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Hopefully this will avoid mangling css files embedded in strings inside
spliced code.
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| | |
that to foo, since it's in the home directory by default.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
characters to 8 bits.
Allow any encoding to be used, as with filenames (but utf8 is the sane
choice). Affects metadata and repository descriptions, and preferred
content expressions.
The question of what's the right encoding for the git-annex branch is a
vexing one. utf-8 would be a nice choice, but this leaves the possibility
of bad data getting into a git-annex branch somehow, and this resulting in
git-annex crashing with encoding errors, which is a failure mode I want to
avoid.
(Also, preferred content expressions can refer to filenames, and filenames
can have any encoding, so limiting to utf-8 would not be ideal.)
The union merge code already took care to not assume any encoding for a
file. Except it assumes that any \n is a literal newline, and not part of
some encoding of a character that happens to contain a newline. (At least
utf-8 avoids using newline for anything except liternal newlines.)
Adapted the git-annex branch code to use this same approach.
Note that there is a potential interop problem with Windows, since
FileSystemEncoding doesn't work there, and instead things are always
decoded as utf-8. If someone uses non-utf8 encoding for data on the
git-annex branch, this can lead to an encoding error on windows. However,
this commit doesn't actually make that any worse, because the union merge
code would similarly fail with an encoding error on windows in that
situation.
This commit was sponsored by Kyle Meyer.
|
| | | |
|
| | | |
|
|/ / |
|
|\ \ |
|
| | | |
|
| | | |
|
| | | |
|