Thanks for detecting and diagnosing that problem.  The JGit 3.3.0 upgrade
happened in git-client-plugin 1.6.5.  It is also in 1.6.6.  The next
release of git-client-plugin (1.7.0) will include the fix.

Hopefully, I'll also have time to write a test which specifically asserts
that bug "stays fixed".

I submitted https://issues.jenkins-ci.org/browse/JENKINS-22391 to track the
bug.

Thanks,
Mark Waite


On Thu, Mar 27, 2014 at 12:20 PM, Christopher Orr <[email protected]> wrote:

> Hi all,
>
> We discovered a subtle bug yesterday with the Git Client plugin and its
> use of jgit (even if you're using the default command-line git
> implementation).
>
> I just noticed that this bug was probably fixed today by a pull request,
> but it's worth letting Jenkins users know about this.
>
>
> 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
>
>
> So, If you see any weird problems with git repos and symlinks, you know
> why! :)
>
> Regards,
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Thanks!
Mark Waite

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to