I'm changing this to a blocker because the only workaround is to downgrade the git plugins (or to entirely sidestep Jgit as suggested in other recent bugs).

Hi,
I have the same issue on my building machine Ubuntu-10.04. This bug prevent me to build several projects.
Where can I find the plug in the version 1.0.3 in order to use the workaround?
Thanks in advance

Note that I was able to downgrade the git plugin directly in the UI, but I had to actually do the git-client one manually. They're all available at:

http://updates.jenkins-ci.org/download/plugins/

That's true. I was as well able to downgrade through Jenkins the git plugin, not this other one.
Thanks for the tip

When you say "the same" you mean you also have recursive symlinks? Also, did the plugin downgrade successfully resolve the issue for you?

Yes Martin. I have some recursive symlinks in my github's repo. The downgrade resolved successfully the issue.
My projects are back online.

Can you please explain your "recursive symlink" layout ? Looks odd

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

I can't explain why that symlink is necessary though I believe it was/is related to the operation of the puppet module involved (I'm not the direct developer of the code itself). It probably resolves differently on the target system (the symlink is ../../.. and the path apt/spec/fixtures may itself have symlinks involved).

That aside, it's unexpected behavior when a change like this breaks Jenkins even though git itself remains perfectly happy with such symlinks (it took a while to figure out where the problem was occurring so I could get our systems back online). It does appear to be a bug in Jgit, and this transition to Jgit opens Jenkins up to other Jgit bugs as well. What drove this sudden switch away from normal git (which is more robust and feature-rich overall)?

And for all this, it would be useful to have the git-client in the list of plugins: it would have saved a lot of time during the downgrade process.

Can you download and test git-client from https://jenkins.ci.cloudbees.com/job/plugins/job/git-client-plugin/34/org.jenkins-ci.plugins$git-client/ ? This one uses a patched JGit version that includes fix proposed for https://bugs.eclipse.org/bugs/show_bug.cgi?id=354367.

@Martin for your information, switch from git-cli to JGit is a long term plan. Using an external process for SCM operation is fragile: it introduce file and process leaks, system dependent issues, and require to parse stdout to extract git results, that is a fragile design. cvs and subversion plugin both switched to pure java implementations.

And that makes sense - once Jgit is up to the challenge. Judging by the number and age of the currently open bugs against Jgit I have to question its current stability but I'm sure eventually it'll be made to work as well or even better than native git despite the shortcomings of doing git in Java (this very bug reflects the fact that Java takes a lot of coaxing (and external hooks) to work seamlessly at a low level with a given operating system and its filesystem structures).

As for dependencies, it appears Jgit requires extensive backward compatibility with various flavors of Java. Looks like it's just trading one kind of fragility for another right now.

This isn't the place for a discussion of the merits of this change, other than to suggest that such a fundamental change get more visibility when it happens. I certainly didn't expect a minor point release of Jenkins to make this large of a change.

I'll monitor the new Jgit bugs closely before we commit to updating to future point releases, and I'll let you know once we've tested this patch. Does this patch fix any other issues due to Jgit in Jenkins or just this one?

Wow the new version of this plugin completely broke my jobs. I have a single symlink from one directory to another (non-recursive) and my builds refuse to update, showing the same "Cannot delete file" error.

I don't think JGit handles symlinks at all does it? I remember reading something a while back about the JGit team not planning on building in symlink support at all until Java gets native support for symlinks. If that's still the case then migrating to JGit is a disastrous idea for those of us in the Linux world.

And what's this about Git CLI being fragile, yada yada? Git CLI has a porcelain mode so that tools can rely on it without worrying about version or output fragility.

My god....

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

Indeed. I realize there's a drive to move to Jgit for git-client, but it's apparently not ready for prime time when it comes to complex filesystems in Unix.

More info on git's "procelain" versus "plumbing" (and the counter-intuitive use of the term porcelain versus the option "--porcelain") can be found here:

http://stackoverflow.com/a/6978402/760905

Since other VCS plugins were switched to pure Java versions, do those plugins handle symlinks and other low-level, OS-dependent features properly? (Of course CVS doesn't know about symlinks to begin with, but SVN certainly does.)

Does git-client plugin 1.0.5 resolve this issue with its switch from JGit implementation back to the Git command line client implementation?

I updated my JIRA with this git-client plugin and so far I didn't see this issue coming back. I should say the new plugin resolve the issue.

Fixed by git-client-plugin 1.0.5 which switches the default implementation back to command line git. The JGit implementation is not yet complete enough to satisfy all the Jenkins use cases.

I just updated to 1.510 (and updated the plugins) and this issue appears to be resolved.

This appears to be resolved.

There seems to be a similar problem with cvs plugin upon cvs update.
A recursive directory causes job to hang forever.
Using strace can see process is recursing into directory to multiple levels . . .
CVS Plugin 2.11
http://wiki.jenkins-ci.org/display/JENKINS/CVS+Plugin
Jenkins ver. 1.562