From Christopher Orr on the Jenkins mailing list:

If Jenkins clones a git repo on a machine running Java 1.6, the repo will be created with "core.symlinks = false" in the .git/config file.
This causes Bad Things to happen if your git repo happens to rely on the use of symlinks.

This happens because the Git Client plugin no longer uses "git clone" to clone a repo, but rather a combination of "git init" then "git fetch", and because the "git init" behaviour is implemented by jgit, even if you're using the default git CLI implementation.

As of jgit 3.3.0, if you're running on a JVM which does not support symlinks (Java 1.6 or older), then the library will explicitly set "core.symlinks" to false when creating the .git directory.

This means "git init" will create a repo which claims not to support symlinks, even if your file system does support symlinks.
"git fetch" will then be executed (via the git binary, rather than jgit) and will respect the erroneous "core.symlinks" config value. Therefore you end up with files rather than the symlinks you expected in your cloned repo.

(We actually saw this on an OS X 10.9 server with Jenkins running under Java 1.7 (with Java 1.6 also on the server as the non-default Java install), but jgit — for some reason — seems to think it's running on Java 1.6 and so believes symlinks aren't supported).

Partly this seems to be a Git Client problem, but also (arguably) a jgit problem, as they explicitly configure new repos to reject symlinks, under the assumption that the repo will always be manipulated via jgit.

But at least this merge from today would appear to fix the Git Client plugin by removing the use of jgit for "git init" for the CLI implementation:
https://github.com/jenkinsci/git-client-plugin/commit/f5b27a9