0.7 fails to commit, errors in Console.app
Reported by Pedro Melo | September 9th, 2009 @ 12:47 PM
I've downloaded 0.7 today, and I'm using it with git version 1.6.5.rc0.
When I try the commit window, and stage some changes, the changes are not staged (I see the spinner in the left-bottom corner appear and disappear quickly, but nothing changes in the UI).
In the Console.app this starts to show
(and keeps showing
every 3 or 4 seconds, even after I close GitX)(I was
mistaken, it stops after GitX exits):
9/9/09 11:44:28 AM GitX Error: 9/9/09 11:44:28 AM GitX Error: 9/9/09 11:44:28 AM [0x0-0x3c73c7].nl.frim.GitX error: patch failed: sites/www.evolui.com/docs/cursos/curso_body.html:49 9/9/09 11:44:28 AM [0x0-0x3c73c7].nl.frim.GitX error: sites/www.evolui.com/docs/cursos/curso_body.html: patch does not apply 9/9/09 11:19:31 AM GitX Window will close! 9/9/09 11:19:31 AM [0x0-0x3b33b3].nl.frim.GitX fatal: Not a git repository (or any of the parent directories): .git
Any help I can give to sort this out?
Thanks in advance,
Comments and changes to this ticket
- State changed from new to open
Yes, we're still having some problems with that. I guess the following is the case (please confirm or deny):
- You're staging using the stage-lines/stage-hunk buttons (and
not staging file-wise) right?
- The hunk/lines you're staging contain some kind of weird characters, like umlauts, UTF-8 stuff, whatever (screenshot of the hunk would be nice).
What's strange is that these message keep appearing after you close GitX
- Yes, only when I use stage-hunk/stage-line buttons;
- This file is Latin1-encoded, and I can only notice the º used in there (http://www.simplicidade.org/share/gitx_commit_prob.png).
Two extra points:
- please ignore the messages keep on appearing after GitX exits, I was mistaken;
- I had this error message with git gui before, but in this case, git gui works fine.
Ah, that explains it then.
I'll describe why this fails, but I think Johannes has already discovered this.
When reading the patch, the stuff goes through PBEasyPipe. Then, on
line 93, we try to convert the data to a usable NSString. This happens
NSString *string = [[NSString alloc] initWithData:data
if (!string) string = [[NSString alloc] initWithData:data
So, we first try to create a UTF8 string from it. If that fails, we
try it as a Latin1 string. In your case, we cane the latin-1 string,
because the º won't encode to UTF8 properly.
This shouldn't be that much of a problem, until we try to apply the
patch. Again this stuff goes through PBEasyPipe, but the data is
written a bit higher in the code (line 86):
[inHandle writeData:[input dataUsingEncoding:NSUTF8StringEncoding]];
So, suddenly we write the º character as UTF8, instead of Latin-1.
Git, having no clue about encodings at all, just sees a different byte
sequence, and says the patch cannot be applied.
So basically there are two problems here.
1) GitX dumps the encoding information of the file. We should probably
store that somewhere in the PBGitFile or whatever we use, to make sure
we can restore it. We then have to extend PBEasyPipe to be able to
output Latin-1 stuff.
2) GitX doesn't report failed patches, so you don't have a clue that
it didn't apply.
Both shouldn't be that hard to fix, though the first is a bit
annoying. I'm a bit tired of all the encoding madness :). The second
especially should be easy to fix.
Forgive my complete noobness regarding Cocoa and GitX, but couldn't you just treat it all as a byte sequence, and convert to NSString only when you need to display it?
Putting it another way: everything read from git and sent to git is treated as a binary blob, and only gets "upgraded" to a NSString for display purposes.