I have the same problem.
The error message originates by GitAPI.java:hasGitRepo():(line 119), it is the exception handler (which sadly doesn't spit out more information). hasGitRepo calls validateRevision which does a launchCommand and parses the output using firstLine - which throws an exception if git dumped multiple lines. This is exactly the case on windows: the output of git rev-parse --verify <my-rev> is <my-ref> newline emptyline. Could we please (at least on Windows) improve that firstLine method to exclude empty lines?

Thanks,

Hannes

Oh, further analysis seems that using git.exe instead of git.cmd (both from msysgit) doesn't end in this issue.

Do you mean to say this issue is fixed after changing git.exe with git.cmd?

yes: I set git binary in jenkins for that host to c:\program files\git\bin\git.exe instead of c:\program files\git\cmd\git.cmd. works like a charm for me.

interesting..... I already have git.exe mentioned in my Jnkins configuration, still I'm seeing this issue, probably I should try to use git.cmd for a change

There is a pull-request mentioning the fix related to this issue, here:https://github.com/jenkinsci/git-plugin/pull/41
I am suprised to find that its "closed" and not merged. Any ideas why ?

I ran into the same problem too. The output of "git rev-parse" just happens to contain a newline. So I happened to look at the manual page of rev-parse and saw this option:

--sq
    Usually the output is made one line per flag and parameter. This option makes output a single
    line, properly quoted for consumption by shell. Useful when you expect your parameter to contain
    whitespaces and newlines (e.g. when using pickaxe -S with git diff-*). In contrast to the
    --sq-quote option, the command input is still interpreted as usual.

Here is an example when run on a windows box:

git rev-parse --sq 64b62d8698dddafb06362a92d3fcaf7a36b91835
'64b62d8698dddafb06362a92d3fcaf7a36b91835'

Maybe this could help resolve the ambiguity of what belongs to the result and what not (some github pull requests mention getting rid of error output mixed together with the actual output).

This is not happening anymore, I'm not sure how it got resolved. Probably the later version might have solved this issue.

Hmm, odd, since I'm seeing this with git version 1.8.0.msysgit.0, Jenkins 1.499, Git plugin 1.1.26.

What is more odd is that if I redirect the output to a file, I don't see extra newline. And seems that other commands, like "git status" have extra newline when run from cmd.exe, hmm...

git-plugin need a valid working-copy to compare remote with current state (there's work in progress so a workspace isn't required anymore)
when the working-copy is corrupted - why it get corrupted is another issue - a new build is required.