git, msysgit, accents, utf-8, the definitive answers
What I’d like is some ‘definitive’ (or at least authoritative) information about:
- Safe to use any utf-8 character in git commit messages?
- Retroactively convert a UCS-2 file to UTF-8 in Git
- Material design icons like “\f222” altered when shared accross linux and windows environements
- UTF-16 support in Git for Windows 2.x
- How do I use octal characters in a git checkout?
- Garbled characters by Jenkins git-plugin encoding conversion?
- What exactly are the ‘problems’? (The symptoms)
- What are the causes? (Briefly)
- In what scenarios is this a show stopper?
- Is there any resolution in sight, or failing that any workarounds?
I hope this question isn’t too vague, I think it would be good to have all of this information in one place to be able to point people to it…
One Solution collect form web for “git, msysgit, accents, utf-8, the definitive answers”
Update Feb. 2017 (Git 2.12): The character width table has been updated to match Unicode 9.0.
update_unicode.sh is moved it into
contrib/update-unicode: see its README.
Update August 2014 (git 2.1): commit a67c821 (Torsten Bögershausen (tboegi)) adds support for Unicode 7.0.
Update April 2014: commit d813ab9 (Torsten Bögershausen (tboegi)) adds support for Unicode 6.3
Unicode 6.3 defines more code points as combining or accents.
For example, the character “
ö” could be expressed as an “
o” followed by
U+0308 COMBINING DIARESIS(aka umlaut, double-dot-above).
We should consider that such a sequence of two codepoints occupies one display column for the alignment purposes, and for that,
git_wcwidth()should return 0 for them.
Affected codepoints are:
U+0358..U+035C U+0487 U+05A2, U+05BA, U+05C5, U+05C7 U+0604, U+0616..U+061A, U+0659..U+065F
Earlier unicode standards had defined these as “reserved”.
Only the range
0..U+07FFhas been checked to see which codepoints need to be marked as 0-width while preparing for this commit; more updates may be needed.
Update April 2012: Unicode support is released in version 1.7.10. See this page for notes and settings you should set.
git config [--global] core.quotepath off git config [--global] i18n.logoutputencoding utf8 git config [--global] i18n.commitencoding utf8 git config [--global] --unset svn.pathnameencoding
recodetree check command scans the entire history of a git repository and prints all non-ASCII file names. If the output is empty, no migration is necessary.
Update February 2012: patches for UTF-8 supports are comming in branch ‘devel’ of msysgit repo on GitHub, including Update less settings for UTF-8 .
The Git for Windows Google+ page mentions:
Karsten Blees’ UTF-8 patches for Git for Windows has now been merged to ‘
This means the upcoming release will support Unicode filenames!
I believe the msysgit issue 80 has the latest on that bug.
Also described in issue 376.
This is what happens:
git on Windows operates on file names and treats them essentially as byte streams.
In your case, the streams happen to be UTF8 encoded text.
git on Windows asks the runtime to create a file, and passes it the byte stream.
Since internally on Windows everything is Unicode, the runtime converts the byte
stream to UTF16 using the currently set locale (aka “codepage”).
That is, it effectively interprets the byte stream as CP949 (Korean) encoded text.
Apparently, some of the UTF8 byte sequences are invalid CP949 sequences, and the conversion fails (“Invalid argument”); or if the UTF8 sequences happen to be correct CP949 sequences, the result is (most likely) a different character.
The true fix
should be on MingW though:
It occurs to me that one solution would be this: solve it at the GCC C run-time
That is, for the mingw GCC run-time library on Windows, make it possible via build-time options to be in a mode where the command-line parameters (passed to
main()) and file I/O functions use the underlying Windows Unicode API calls, and translate to/from UTF-8 encoding in C’s standard function APIs that use byte-strings.
That would “just work” for git perhaps, and could be useful for other Linux-originated open source projects running the Windows environment.
ak2 comments that MingW isn’t the right place for this fix:
“MinGW compilers provide access to the functionality of the Microsoft C runtime and some language-specific runtimes.
MinGW, being Minimalist, does not, and never will, attempt to provide a POSIX runtime environment for POSIX application deployment on MS-Windows.
If you want POSIX application deployment on this platform, please consider Cygwin instead.”
There is some work in progress on a msysgit variant to support unicode.