[JENKINS-47609] Add clone option "core.longpaths" to enable .git/config "core" property

[rishabhBudhouliya]

JENKINS-47609

**The figure shows addition of the new option.**

Some users face a 260 character limit for filenames in a Windows environment although Git has a limit of 4096 characters for a filename.

By setting core.longpaths to true in git config, we bypass this limit. This clone option provides this setting.

Checklist

• I have read the CONTRIBUTING doc
• I have referenced the Jira issue related to my changes in one or more commit messages
• I have added tests that verify my changes
• Unit tests pass locally with my changes
• I have added documentation as necessary
• No Javadoc warnings were introduced with my changes
• No spotbugs warnings were introduced with my changes
• I have interactively tested my changes
• Any dependent changes have been merged and published in upstream modules (like git-client-plugin)

Types of changes

• New feature (non-breaking change which adds functionality)

[rishabhBudhouliya]

The build will fail because the changes made in git-client-plugin have to be merged first.

Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure

[2020-03-19T12:10:55.803Z] /home/jenkins/workspace/Plugins_git-plugin_PR-856/src/main/java/hudson/plugins/git/extensions/impl/CloneOption.java:[146,16] cannot find symbol

[2020-03-19T12:10:55.803Z]   symbol:   method longPath(boolean)

[2020-03-19T12:10:55.803Z]   location: variable cmd of type org.jenkinsci.plugins.gitclient.CloneCommand```

[rishabhBudhouliya]

Since there is an issue with git-for-windows, I'd like your opinion on how to move forward on this case.

Not all git commands honor longpaths=true property, hence we might not be able to implement this feature until I write a regression test for them, and they work towards a fix after that.

[MarkEWaite]

The build will fail because the changes made in git-client-plugin have to be merged first.

The "incrementals" facility allows a plugin to depend on an incremental (unreleased) build of another plugin. In this case, you can submit a pull request to git client plugin and then read the incremental name from the ci.jenkins.io artifacts of the pull request build. Declare the git-client-plugin dependency in the pom on that incremental version and build with it.

[MarkEWaite]

Since there is an issue with git-for-windows, I'd like your opinion on how to move forward on this case.

I think we should proceed as though the git for windows issue is fixed. It would be good to have this option in the CLI implementation of the git client plugin, even if it does not handle all cases yet.

[rishabhBudhouliya]

@MarkEWaite Would it be acceptable to remove the test cases then? I can raise a PR with the feature but I haven't tested it for all cases. It is not working in the case of a directory clone path >255 char, not able to access the local git config file.

[MarkEWaite]

Rather than remove the test cases, you can place the @Test annotation in a comment so that the tests will be compiled but not executed. Then also include a comment that the test should be enabled once the command line git issue is resolved.

[MarkEWaite]

I'm closing this pull request for now, since it depends on a change in git for windows. We can reopen it in the future if we see the change in git for windows.