The work around works for me, but I had to remove "Wipe out workspace after build" post build step as well as restart the slaves. I did not have the "Wipe out workspace before build" option enabled.

Edit: of course, I won't really know until I re-run the build.

I am also seeing this happening. My setup is as follows:

• Jenkins 1.506 (all plugins up to date as of 2013/03/20)
• Build master and slaves are all RedHat 5 machines.
• Using git for all SCM
• Currently using "Wipe out workspace before build" option

If I log into any build slave and use the "lsof" command to see what processes have files open, I see that the java instance of the build slave has files open in the .git/objects/pack/ directory of several jobs.

I have to restart all build-slaves that have files open before I can run the job again.

EDIT: I also want to say that I'm seeing this even when the branch specifier is explicit: "origin/master". no wildcard is being used...

EDIT2: So, I've figured out how to work around my issue. If I add this JVM option to each slave, everything works fine:
-Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true

This issue really affects our projects, we had lot of projects failing because of this issue. Please consider fixing it soon.

Since Omid was able to confirm that the problem is resolved with useCLI=true, and useCLI=true is now the default with git-client-plugin version 1.0.5, I believe this issue is resolved. I was unable to duplicate the issue with many different jobs on a Windows computer.

I used the latest released git client plugin (1.0.5) and the latest git plugin (1.3.0) with two different Windows machines (one Windows 6.1 kernel [Windows Home Server 2011], one Windows 6.2 kernel [Windows 8]) and was unable to duplicate this problem. As far as I can tell, it is resolved.

This was working correctly in Git plugin 1.5.0 so long as the command line implementation was used. It no longer works correctly in Git plugin 2.0, even when the command line implementation is used. Some portion of the Git plugin or Git client plugin seems to be opening a pack file and not closing it.

Refer to JENKINS-19994 for a bug which may be a duplicate of this bug.

The automated tests executed by "mvn install" on the git-client-plugin repository seem to show the same problem. When those tests are run on Linux, they pass. When the same tests are run on Windows, several of the tests fail with the message "Failed to clean up temp dirs"

The tests which are failing include:

test_checkoutBranchFailure(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs
test_setSubmoduleUrl(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs
test_show_revision_for_single_commit(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs
test_getAllLogEntries(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs
test_revListAll(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs
test_fetch_with_updated_tag(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs

Within the failure details, the message "IOException: Unable to delete ... pack" is listed.

Note that the same unit tests pass for the command line implementation. I think that makes the current behavior different from the originally reported behavior. The original report required that there was a certain format for the branch to build, while the unit test failure shows that it will fail for any case which uses JGit as the git executable instead of using the command line as the git executable.

Unfortunately, those test failures only happen in the JGit implementation, not in the CLI implementation. This bug report was submitted confirmed as a problem with both the JGit and the CLI implementations, so fixing the JGit specific test failures will not be enough.

Report conditions seem very similar in JENKINS-19994

Using git-client-plugin 1.6.2 and git-plugin 2.0.1, I can consistently wipe the workspace on Windows 7, Windows 8.1, Windows Home Server 2011 so long as I use the default Git implementation (which is the command line).

If I switch to using JGit as the implementation, the job fails because the pack file is still busy. That's the condition described by JENKINS-19994 and JENKINS-18843.

Can anyone else describe conditions where the command line git implementation shows this problem on any platform?

Confirmed fixed in git-plugin 2.0.1 and git-client-plugin 1.6.2 for command line implementation.

JENKINS-19994 and others describe the same issue for the JGit implementation, which is not yet fixed.

Since command line implementation is the default implementation and the most feature rich, this bug is resolved.