We recently upgraded the git-client and jenkins Git plugins to the latest versions.

We have several projects that contain symlinks that are checked directly into git.

When testing using vanilla git on the commandline, the repo is created correctly either using 'git clone' or 'git init/git fetch'. The base .git/config file looks like this:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

However, cloning this same repo using the Jenkins plugins yields the following base config file:

[core]
symlinks = false
repositoryformatversion = 0
filemode = true
logallrefupdates = true

The result is that our symlinks end up being local text files with references to the file it's supposed to link to, so those builds fail.

This appears to be a similar issue to https://issues.jenkins-ci.org/browse/JENKINS-21168, except on the Linux platform. I don't believe core.symlinks should be set at all on Linux, generally speaking.

I tried starting the slave agent with JAVA_ARGS=-Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true

but I get the same results.

If I'm reading the Windows version of this bug correctly, I think it's using JGit to create the initial repo, regardless of what we set in the JAVA_ARGS. Perhaps the bug lies there.

It's also worth noting that we don't even have a JGit instance defined.

We've worked around it by not using the git/git-client plugin and cloning our repos on these jobs using explicit git commands in our execute shells. Will consider downgrading plugins if it's not an easy/quick fix.