Closed wickchucked closed 9 years ago
divmain
commented
9 years ago I'm going to do some work to the logging feature to better support cases like this. As it is, I don't think I have enough information to go on. Most likely, the file is not valid UTF-8. You mentioned you were using SublimeGit before this without issue, so I'll look for a workaround.
Do other commands succeed (normal diff views, for example)?
weslly
commented
9 years ago I'm having a similar error when trying to open the log on a file:
Traceback (most recent call last):
File "/Users/weslly/Library/Application Support/Sublime Text 3/Packages/GitSavvy/core/git_command.py", line 102, in git
stdout, stderr = stdout.decode(), stderr.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 1036297: invalid continuation byte
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 556, in run_
return self.run(edit)
File "/Users/weslly/Library/Application Support/Sublime Text 3/Packages/GitSavvy/core/commands/show_commit.py", line 29, in run
content = self.git("show", commit_hash)
File "/Users/weslly/Library/Application Support/Sublime Text 3/Packages/GitSavvy/core/git_command.py", line 105, in git
raise_error(e)
File "/Users/weslly/Library/Application Support/Sublime Text 3/Packages/GitSavvy/core/git_command.py", line 86, in raise_error
raise GitSavvyError(msg)
GitSavvy.core.git_command.GitSavvyError: 'utf-8' codec can't decode byte 0xe2 in position 1036297: invalid continuation byte@weslly, UTF-8 is assumed in handful of places in GitSavvy. Are you working with files encoded with something other than UTF-8? This is complicated to robustly support, but I'm thinking through some possible strategies.
asfaltboy
commented
9 years ago This just happened to me when opening the detailed commit view with staged files with character encoding other than UTF-8 (it was windows-1255 in my case); I guess rendering the diff is the issue:
Traceback (most recent call last):
File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 556, in run_
return self.run(edit)
File "/Users/big/Library/Application Support/Sublime Text 3/Packages/GitSavvy/core/commands/commit.py", line 94, in run
initial_text += self.git("diff", "--no-color", "--cached")
File "/Users/big/Library/Application Support/Sublime Text 3/Packages/GitSavvy/core/git_command.py", line 111, in git
raise_error(e)
File "/Users/big/Library/Application Support/Sublime Text 3/Packages/GitSavvy/core/git_command.py", line 92, in raise_error
raise GitSavvyError(msg)
GitSavvy.core.git_command.GitSavvyError: 'utf-8' codec can't decode byte 0xec in position 1868: invalid continuation byteInterestingly enough, when opening this windows-1255 file in sublime, I see a helpful message in the console: unable to auto detect encoding for ~/dev/test_win1255.txt, using fallback encoding Western (Windows 1252). This behavior also seems to be used in vim, when I use it as git editor, the characters just seem encoded as Western, which is better than no output at all.
This fallback would be a simple try/except clause, such as in asfaltboy/GitSavvy@ca876dbd49842cb5086d052d83b19fc8f1019091. Let me know a PR is welcome.
If we really want to make a smarter guess, then we could use chardet:
chardet.detect() the command result row by row.UTF-8.divmain
commented
9 years ago @asfaltboy, here's a thought - a noisier failure might be warranted. In the case of an inline-diff, falling back is probably fine. But there may be cases where silently falling back could be very undesirable. What are your thoughts on something like:
def decode_stdout(stdout):
try:
stdout = stdout.decode()
except UnicodeDecodeError as err:
if sublime.ok_cancel_dialog("GitSavvy was unable to parse content successfully. Would you like to fallback to the default encoding? Text may not appear as expected.", "Fallback?"):
return stdout.decode("windows-1252")
raise err
# later in the `git` method...
stdout, stderr = decode_stdout(stdout), stderr.decode()Sure, that seems reasonable, tested it out, looks good:
divmain
commented
9 years ago Awesome. no need to PR, I'll just bring over your commit. Thanks!
divmain
commented
9 years ago Closed by 121f932f2e5d39163d12da9e2f36ad3542e70c52.
Here is the dump from what I could see in the Sublime console, it wasn't popping up in a new window form me when I tried to view recorded log. Let me know if you need anything else.
This is referencing the thread I started in #127