Downgrading the git plugin to 1.2 and git-client plugin to 1.0.3 has got me back to a working state for now.

Same here, we had to downgrade to 1.20 and 1.0.3, and also had to enable the useCLI flag.

1.30 and 1.0.4 broke most of our jobs, and downgrading to 1.1.27 is impossible because the 1.20 upgrade causes a backward-incompatible change in all build.xml and config files.

Same here, works with Git Plugin 1.2.0 and Git Client Plugin at 1.0.3, fails with newer versions (in my case: a symlink present in the Git repos):

17:31:05 hudson.plugins.git.GitException: Could not checkout 8b3456787edbe0043627368bb1aa2c1f36625440
17:31:05 at org.jenkinsci.plugins.gitclient.JGitAPIImpl.checkout(JGitAPIImpl.java:68)
[...]
17:31:05 Caused by: org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files:
17:31:05 debian/lua5.2.dh-lua.conf
17:31:05 at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:244)
17:31:05 at org.jenkinsci.plugins.gitclient.JGitAPIImpl.checkout(JGitAPIImpl.java:64)
17:31:05 ... 16 more

I had this same issue with Git Plugin 1.3.0 and Git Client Plugin 1.0.4. Something about the way CocoaPods sets up the directory structure was confusing the JGit checkout for all of our projects using that to install iOS dependencies (other projects were unaffected).

The new Git Client Plugin 1.0.5 released today fixes the issue. Thank you!

Fixed in 1.0.5

1.0.5 simply defaults to the workaround; doesn't resolve this issue at all. Additionally, the person fixing the issue and/or reporting the issue should probably be the one(s) to confirm the issue resolved.

When will it be available for download?

The Git Client Plugin 1.0.5 was released earlier today. If you're checking for updates under "Manage Plugins", make sure to go to the Advanced tab and click the "Check Now" button to refresh the plugin metadata.

@Dallas, I believe git-client-plugin 1.0.5 acknowledges that the JGit implementation is not yet mature enough for general purpose use as a replacement for the git command line implementation. When the JGit implementation has the necessary features, the plugin maintainer will consider changing the default to use JGit instead of using the command line.

For at least some bug reports, there is a robot that resolves the issue when a submission is made that declares the issue is resolved. I interpreted that to mean that anyone can resolve an issue, including the submitter of the change which fixes the issue. The project does not seem to require or mandate that the issue can only be resolved by the person who reported the issue. In this case, I think it would be great if the original submitter would install git-client-plugin 1.0.5 and confirm the issue is resolved, but in the general case, if the issue is resolved, anyone can mark it as resolved.

The plugin maintainer can still refer to this bug report (and others) before the next time when it is chosen to make JGit the default implementation instead of using the CLI implementation.

No response from original submitter. Fixed in git-client-plugin 1.0.5 by reverting to the git command line implementation until the JGit implementation is able to handle the Jenkins use cases.