As far as I can tell from pom.xml, the JGit 3.7.1 code sets the core.symlinks value to false. At least that is what the test asserts in GitAPITestCase for JGit and for git on Windows. Those tests passed at the release of git plugin 2.4.0 and are currently passing.

Maybe the default setting will change at JGit 4.0? That is the time when JGit switches to require Java 7 as its minimum JDK. The git plugin probably won't switch to Java 7 for at least another 6 months so that we allow users time to move forward to newer Jenkins versions.

Alternately, the JGit authors may be assuming it is the responsibility of the caller to adjust the settings of core.symlinks from the default "false" to "true" if they are desired.

After investigation, it seems that symlinks management in JGit is handled by a specific jar (org.eclipse.jgit.java7) which extends the behavior of org.eclipse.jgit classes, and which has not been included in the git-client plugin.

We have been able to see symlinks working by just:

• compiling org.eclipse.jgit.java7-3.7.1.201504261725-r.jar (the one missing in git-client)
• droping it in plugins/git-client/WEB-INF/lib/
• compiling org.eclipse.jgit-3.7.1.201504261725-r.jar (just because the original one from git-client is complaining about signature mismatch with the previous jar we compiled)
• drop it as well to override the original one in plugins/git-client/WEB-INF/lib/

Nicolas, do you think the missing jar could be added in the next release of git-client, with a quick updated release of the git plugin after that?

Or just dropping in plugins/git-client/WEB-INF/lib/ the missing jar downloaded here: http://jcenter.bintray.com/org/eclipse/jgit/org.eclipse.jgit.java7/3.7.1.201504261725-r/org.eclipse.jgit.java7-3.7.1.201504261725-r.jar

(found on that page: http://mavensearch.io/repo/org.eclipse.jgit/org.eclipse.jgit.java7/3.7.1.201504261725-r)

• and restart Jenkins.

I doubt that we can include the "java7" jar file in the current git client plugin, since I suspect that those files are a separate jar file because they require java 7. The git client plugin must continue to run on Java 6 until it is updated to depend on Jenkins 1.625 or later. Inserting a java 7 requirement risks breaking users that are running slaves on Java 6, or even users running an older Jenkins version with the master on Java 6.

Rather than recompile, you might consider downloading the jar file as built and released by the Eclipse project. I believe it is located in the maven repository as this jar file.

Damned, you're right, I guess. As mentionned here:

Native symbolic links are supported, but only if you are using Java 7 or newer and include the org.eclipse.jgit.java7 jar/bundle in the classpath, provided the file system supports them. For Windows you must have Windows Vista/Windows 2008 or newer, use a non-administrator account and have the SeCreateSymbolicLinkPrivilege.]:

Would you already be able to give me an ETA for the git client plugin update which will set Jenkins 1.625 as a req? (weeks, months, year(s)?)

I guess there is no way to cleverly and conditionally activate the java7 jar only with Java 7 or more?

Also, thanks for the link to the maven central jar.

The git client plugin does not move to a new base version of Jenkins until that base version is at least 6 months old. Often the base version is closer to 18 months old before the plugin is updated to use a newer base version. The 1.625 release is the first LTS release to not support Java 6, so I suspect it will be 6-9 months after the release of 1.625. That means it is at least 6 months away before Java 7 will be required for the git client plugin.

Hi,
After testing, it seems that we can have the java7 jar in the plugin all the time:
When running with Java 7 or more, we have symlinks working as expected, and with Java 6, the plugin still works properly, although without symlink functionality, of course.
Could you give it a try?
If you confirm, git-client could be updated without waiting 6+ months, even in the forthcoming 12.0.0, without any bad side effect.