short term workaround is either to run jenkins with -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true, or check "clean workspace after checkout" - this option will clean workspace ...before (sic!) checkout and avoid conflict.

Could you also tell me if there is anything during your build that could have touched support/tools/relink/macholib/MachO.py ? I'm looking for a public git repository I could use to reproduce this issue.

We also experienced this issue after upgrading. We determined that our issue was due to JGit (and therefore git-plugin) not supporting symbolic links and our git repository has multiple symbolic links. We also used the workaround -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true to resolve the issue, but we're wondering what the actual implementation will be to resolve this issue.

Can you please try SNASPHOT build https://jenkins.ci.cloudbees.com/job/plugins/job/git-client-plugin/33/org.jenkins-ci.plugins$git-client/artifact/org.jenkins-ci.plugins/git-client/1.0.5-SNAPSHOT/git-client-1.0.5-SNAPSHOT.hpi ?

This one includes a possible fix to ask JGit to handle the detected conflict by itself

relates to https://bugs.eclipse.org/bugs/show_bug.cgi?id=354367

https://jenkins.ci.cloudbees.com/job/plugins/job/git-client-plugin/34/org.jenkins-ci.plugins$git-client/ provably is a better candidate to get this issue fixed : it used a patched version of JGit to include https://bugs.eclipse.org/bugs/show_bug.cgi?id=354367 proposed fix

I installed https://jenkins.ci.cloudbees.com/job/plugins/job/git-client-plugin/34/org.jenkins-ci.plugins$git-client/ and restarted Jenkins and still have this issue.

hudson.plugins.git.GitException: Could not checkout 00f6e95c8ff6cc6f7ca544fa07124dd3edaa0586
at org.jenkinsci.plugins.gitclient.JGitAPIImpl.checkout(JGitAPIImpl.java:68)
at hudson.plugins.git.GitAPI.checkout(GitAPI.java:208)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1261)
at hudson.plugins.git.GitSCM.access$1200(GitSCM.java:57)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1220)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1196)
at hudson.FilePath.act(FilePath.java:865)
at hudson.FilePath.act(FilePath.java:838)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1196)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1353)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:689)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:594)
at hudson.model.Run.execute(Run.java:1567)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with file: Cannot delete file: ios/PorkButt/opentok-ios-sdk/Opentok.framework/Headers/OTError.h
at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:246)
at org.jenkinsci.plugins.gitclient.JGitAPIImpl.checkout(JGitAPIImpl.java:64)
... 16 more
Caused by: org.eclipse.jgit.errors.CheckoutConflictException: Checkout conflict with file: Cannot delete file: ios/PorkButt/opentok-ios-sdk/Opentok.framework/Headers/OTError.h
at org.eclipse.jgit.dircache.DirCacheCheckout.cleanUpConflicts(DirCacheCheckout.java:1011)
at org.eclipse.jgit.dircache.DirCacheCheckout.doCheckout(DirCacheCheckout.java:413)
at org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:391)
at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:242)
... 17 more

There are symlinks in there.

In our environment, this workaround doesn't solve this issue.

 -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true

However, we solved with combination below, which described at http://mrkn.hatenablog.com/entry/2013/03/18/225556 (Japanese).

• Git Plugin : 1.3.0
• Git Client Plugin : 1.0.3

If you're using a master/slave configuration you need to set the argument in your slave configuration as well.

Ah, That's make sense. Thanks

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.