Thanks for great app. I want to use Japanese in the commit log, but the combining character string is difficult to read or not display at all.
I extract the commit objects from .git/objects and check the raw commit message bytes.
Original Message:
がぎぐげご
Commit from Git commandline:
e3818c e3818e e38190 e38192 e38194
Commit from Github client:
e3818c e3818e e38190 e38192 e38194
Commit from SourceTree:
e3818b e38299 e3818d e38299 e3818f e38299 e38191 e38299 e38193 e38299
- http://www.fileformat.info/info/unicode/char/304c/index.htm
- http://www.fileformat.info/info/unicode/char/304b/index.htm
- http://www.fileformat.info/info/unicode/char/3099/index.htm
> The combining characters are rarely used in full-width Japanese characters, as Unicode and all common multibyte Japanese encodings provide precomposed glyphs for all possible dakuten and handakuten character combinations in the standard hiragana and katakana ranges.
- is duplicated by
-
SRCTREE-1116 Please support convert UTF8-MAC (NFD) to UTF8 (NFC) in commit message
-
- Closed
-
[SRCTREE-978] Unicode combining character is used to express Japanese 'Dakuten'.
Kengo Koseki
added a comment - Thank you so much for reconsidering this issue!
Actually, hg commit can use the --logfile option, so we should be able to support this there too.
Re-open: try redirecting git commit message via a file to resolve this. Not possible in hg though.
@hironytic: Hmm, yes redirecting via a file might work for git, will try that.
@Kengo: yes, this is just the standard result of 'git log --grep'
Kengo Koseki
added a comment - I noticed that SourceTree couldn't find NFC UTF-8 commit message.
> https://skitch.com/koseki/8ac13/1-tmux
I was pointed out that the above rendering result is produced by Tmux, not iTerm2.
Kengo Koseki
added a comment - I noticed that SourceTree couldn't find NFC UTF-8 commit message.
https://skitch.com/koseki/854b2/users-koseki-tmp-sourcetree-git
> https://skitch.com/koseki/8ac13/1-tmux
I was pointed out that the above rendering result is produced by Tmux, not iTerm2. I'm also suffering from this problem.
SourceTree is going to be just a repository viewer for me.
If hg/git supported reading the commit message from a file that would be a workaround, but they don't AFAICT.
I think git has an option; -F or --file=.
Please, please try this!
Unfortunately, this is unavoidable when calling external processes. NSTask will always call [NSString fileSystemRepresentation] on all arguments, which will always produce decomposed unicode characters because of the way HFS+ works. It isn't possible to subclass NSString to make this behave any differently, and NSTask will not accept anything except NSStrings as arguments.
Therefore sadly, I won't be able to change this behaviour, and messages will always be passed as decomposed characters.
Subclassing NSString isn't an option.
Because of the nature of class clusters, string objects aren’t actual instances of the NSString or NSMutableString classes but of one of their private subclasses.
I'm not sure there's anything I can do about this.
Oddly this doesn't explain why copying & pasting other text avoids this issue, or why the characters are rendered differently in the first place.
In 1.5 all commit message data is redirected via a file which avoids NSTask's automatic conversion to decomposed unicode (done to assume compatibility with HPFS+).
I've tested this with the examples and the original non-decomposed unicode gets through to the commit message correctly.