Git: Cannot parse Git version string

[whotired]

I install git 2.18.0 and 64 bit for Windows 7. While clicking "Gig GUI here" and getting error:
git-gui:fatal error
Cannot parse Git version string
The path in environment virable is "C:\Program Files\Git\cmd" as default.

[dscho]

This is really little information to go on.

I only saw something like this when GIT_TRACE was set, but with those few breadcrumbs thrown leisurely into my vague direction, it is hard to tell.

[shiftkey]

:wave: Hi @dscho.

I wasn't quite at the point of reaching out to you on this but I've encountered this same issue with a handful of GitHub Desktop users in terms of Git LFS not being able to read any output from git --version or git version.

The investigation so far is happening in https://github.com/desktop/desktop/issues/5247 but I'll try and summarize it here:

• git-lfs does a version check that it has a valid git available by spawning git version
• for some users, no stdout is returned and so git-lfs raises an error to Desktop
• one user (not @whotired) also tried this out with vanilla Git for Windows (2.18.0.windows.1) and encountered the above error message with git-gui
• poking at the source I see this is the same pattern as what git-lfs is encountering (no stdout returned, so :boom:)

Things I've tried to eliminate as the root cause:

• another program on PATH named git.exe that is called instead
• some third-party tool like anti-virus that likes to interfere with spawned processes (Carbon Black gets a mention but users don't think that's to blame)

Any other thoughts or things to eliminate would be greatly appreciated.

[dscho]

for some users, no stdout is returned and so git-lfs raises an error to Desktop

That is indeed strange.

another program on PATH named git.exe that is called instead

Wait, what?

[shiftkey]

another program on PATH named git.exe that is called instead

Wait, what?

Some other program that just _happened_ to be named git.exe but didn't handle arguments or error. Don't worry about it, it's a long shot that we've got that sort of collision happening.

[shiftkey]

Just had word that Carbon Black is to blame and they're rolling out an update to fix this: https://github.com/desktop/desktop/issues/5247#issuecomment-413303337

@whotired can you confirm whether you have Carbon Black installed?

[whoisj]

Perhaps something like GetFileVersionInfoExW would be safer?

[shiftkey]

@whoisj safer for whom?

[whotired]

@shiftkey Yes, Carbon Black has been installed on 2018-8-12 on my machine. But my colleague has same program and no this error "Cannot parse Git version string", he can open git-gui correctly.

[shiftkey]

@whotired it's not clear to me which version has the issue, but hopefully @mpauser can share once they've received an update.

[whotired]

@shiftkey Thanks

[whoisj]

@shiftkey my point was instead of running an external process, which could be intercepted by interventionist services like Carbon Black, it could be _safer_ to just use the OS provided API to query the version information.

Example (written too quickly, it's a mess but you get the idea):

#include "pch.h"
#include <iostream>
#include <Windows.h>

#pragma comment(lib, "mincore.lib")

static const wchar_t *path_to_git = L"C:\\Program Files\\Git\\cmd\\git.exe";
static const wchar_t *prodver_format = L"\\StringFileInfo\\%04hX%04hX\\ProductVersion";
static const wchar_t *vfi_trans_format = L"\\VarFileInfo\\Translation";

int main()
{
    struct file_version_info {
        void *data;
        unsigned int size;
    } culture, details, version;
    struct culture_info {
        unsigned short language;
        unsigned short codepage;
    } *info;
    wchar_t query_string[256];
    unsigned long ret;

    version.size = GetFileVersionInfoSizeExW(FILE_VER_GET_NEUTRAL, path_to_git, &ret);

    if (version.size <= 0)
        goto failure;

    ret = 0;
    version.data = malloc(version.size);

    if (!GetFileVersionInfoExW(FILE_VER_GET_NEUTRAL, path_to_git, 0, version.size, version.data))
        goto failure;

    if (!VerQueryValueW(version.data, vfi_trans_format, &culture.data, &culture.size))
        goto failure;

    for (int i = 0; i < (culture.size / sizeof(culture_info)); i += 1)
    {
        info = &((culture_info *)culture.data)[i];
        query_string[wsprintfW(query_string, prodver_format, info->language, info->codepage)] = 0;

        if (!VerQueryValueW(version.data, query_string, &details.data, &details.size))
            continue;

        wprintf(L"%s", (wchar_t*)details.data);

        goto clean_up;
    }

failure:
    ret = GetLastError();

    if (ret > 0)
        wprintf(L"fata: error 0x%04h.\n", ret);

    wprintf(L"Unable to read version information from \"%s\".\n", path_to_git);

clean_up:
    if (version.data)
        free(version.data);

    return ret;
}

The output is "2.18.0.windows.1".

[shiftkey]

@whoisj no problem. It's just that for git-lfs (that originally encountered this issue) and git-gui have to support other OSes to Windows, and I've not looked into the equivalents to GetFileVersionInfoExW there (if they even support it).

[dscho]

I guess it's not only that. While the version check would be helped by GetFileVersionInfoExW(), both Git LFS and Git GUI have to spawn Git for other purposes, like, to let Git do real work. And I have no doubt in my mind that those services like Carbon Black (or more commonly, at least as far as appearances on this bug tracker go, Comodo Internet Security) will wreak havoc with those calls anyway. We can try to work around their bugs all we want, eventually it is up to them to fix their software (or to tell us precisely what bug Git for Windows has, because so far they haven't come up with any convincing bug report).

[whotired]

This morning I opened my computer, it did windows update, then I clicked git-gui.exe, it can be opened correctly without the error "Cannot parse Git version string", I thought the windows update fix the issue. But when I restart the computer two hours later, the same error occured again :(
The updates as below

[dscho]

I'm going to close this out because I don't believe there's anything we can do in Desktop to address this, and it seems like updates to products like Carbon Black should resolve the issue eventually. (See also https://github.com/desktop/desktop/issues/5247#issuecomment-424712141)