git GUI: fatal error Cannot parse Git version string:

[equihuam]

A few day ago I started to get this error almost all the time, althoug some times git GUI actualy runs in my machine. Dont know what is happening. I think it also has to do with tortoise git failing. I had used it for a long time without problem until know. I have uninstalled, clean the registry, reinstalled and nothing seems to solve the problem. Any advice?

I am running windows 8 pro (64) and [Git-1.8.5.2-preview20131230.exe], although I tried also version 1.8.0 but got same results.

[sschuberth]

This basically seems to be a duplicate of msysgit/msysgit#103 (and thus http://code.google.com/p/tortoisegit/issues/detail?id=1533), however it's interesting to see this happening with git-gui now instead of TortoiseGit. Maybe this helps us reproducing the issue, although I still have not seen it myself.

[dscho]

@equihuam first thing you need to do is verify that git --version gives you the correct output. Next, there is always the possibility that the output is not read completely; this is harder to debug and will require your compiling Git from scratch.

[equihuam]

It gets it right:

[kusma]

@equihuam: Two things worth trying:

1. "git --version | od -c" to see that the output is not somehow garbled when not going directly to the console
2. Setting $LANG to en_US before starting git-gui

[equihuam]

1. the result of : git --version | od -c was: sh.exe": od: command not found
2. I set the environment variable LANG to en_US as a system var in windows.

I did't actualy find a way to reproduce suggestion 1 on windows.
No change what so ever. Stil not working same error.

[kusma]

Sorry, we probably don't ship 'od' with Git for Windows. Try "git --version > temp.txt", and inspect the result in a hex-editor instead?

Thanks for testing the LANG-switch, though. The "Aceptar" text instead of "OK" indicated that you were on a non-english Windows, but that didn't seem to be the cause.

[dscho]

@equihuam there is probably a better way to handle this issue than let @kusma explain what the od tool is supposed to do: the internet knows that, too, and unlike @kusma, it does not need sleep.

Also, I would strongly suggest following @sschuberth's advice and read up on the other issues. Did you do that yet? In particular, msysgit/msysgit#103 (comment) seems relevant.

Do not get me wrong, I'd like to see this fixed, but it will not happen unless you contribute a considerable amount of time and effort to fix the bug. We will help you, of course, by pointing you into the right direction and commenting on code.

[equihuam]

I have red the indicated post and the few other that a found in some other places, non very promising to me as at least one of them ended in a re-install of operating system!!!!! I will invest some time with you if I get clear directions to do it. So, I gather the next thing will be to download the full package and attempt to compile it????

Any way, here it is the hex dump of the temp.txt file:

[dscho]

@equihuam yeah, they reinstalled the operating system. But if you read closely, you figured out that 1) it was not necessary and 2) it did not solve anything.

The net installer is what you want to download and install.

Once installed, you get a Bash in the development environment and can cd to /src/git-wrapper/. This has all the sources for the Git wrapper that seems to be the problem. I am guessing here because this ticket does not contain information about the Git Bash vs Cmd choices taken while installing Git for Windows, and my guess is it was Cmd.

You can recompile the Git wrapper using /src/git-wrapper/release.sh. It will be installed into /cmd/git.exe. To figure out whether that Git wrapper is called correctly, you could patch the source code to write debug messages into a file or some such.

[equihuam]

I assume I have to remove the previous version of Git from the preview package. So after a long while I have now a copy of msysgit 1.9 in my machine. I can patch it and compile to display debug messages on screen succesfully. What variable should I be looking into?

[dscho]

@equihuam you would not remove the previous version but replace just /cmd/git.exe with the newly compiled version.

The problem to look into is whether the version is correctly printed by /cmd/git.exe version as called from git gui, and if it is, why git gui does not see it.

It most likely has something to do with channels being closed before the output is read, or some such.

[equihuam]

Well, I am not so sure of what to do. In fact I have very limited understanding of C, but I have done the following:

Set up a number of print lines along the code to follow the path of processing. Labelled the messages with the line number of where I put them. This patched wrapper produced the following output:
C:\msysgit\cmd>git --version
Miguel-line 55: C:\msysgit
Miguel-line 57: C:\msysgit\bin\git.exe
Miguel-line 120: git --version
Miguel-line 144: git.exe
Miguel-line 157: git.exe --version
git version 1.9.0

Now when calling the Git-GUI I got the following result:

and by the way when I put the git.exe patched in the previous installed git/bin it loops for ever, that is why the user interrupt message. hope there is something of use here, but in any case I will require more specific instructions, sorry about that.

[dscho]

Good progress! Since it works when started interactively and loops forever when started from within git gui, you have a good starting point to debug further (and the same reason that makes it loop forever might be responsible for the breakage you are trying to fix).

So now I suggest digging further. There are two lines of attack I would follow:

1. Try to attach to the process while it is hanging: In a separate msysGit Bash, call ps to figure out the process ID (pid) of the hanging process, then call gdb /src/git-wrapper/git.exe <pid>. Once it attached successfully (which it might not do, I experienced rare problems on Windows with that), you can see the stack trace using the command bt and go up and down in that list using the up and down commands, list the context in the source code with l. You might want to recompile the wrapper with debug information by adding the -g flag to CFLAGS in /src/git-wrapper/Makefile before compiling it again (and copying it again).
2. Failing the first approach, I would try to pin-point more exactly where things go awry using more debug messages. For example, I would output br just after the call to CreateProcess. I would also try to write to stderr using the Win32 API just before and/or after CreateProcess. And finally, I could imagine that it would be informative to write debug messages in

   git/help.c

   Line 411 in 0fce85d

   printf("git version %s\n", git_version_string);

   to a file, i.e. { FILE *f = fopen("C:\tmp.txt", "w"); fprintf(f, "I am here!\n"); fclose(f); }. That way, you can determine whether the code executed until that point even if the debug messages are not shown.

[equihuam]

ps is not catching the process, so path "1" failed!!!!!. I used windows task manager and found that many git processes are being launched (added de -g flag):

So it is not properly hanging!!!!!

Regarding 2. I haven't done all, but added the br message in two points.

[sschuberth]

Interesting. Looks like the git wrapper is calling itself over and over again instead of the real git exe. The question is how and why this can happen.