Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: git-plugin
-
Similar Issues:
Description
underlined textMethod `submoduleUpdate` should accept `reference` the same way as `clone` does.
git submodule update --init --recursive --reference $reference
Speeds up submodule update when using a local mirror.
Attachments
Issue Links
- depends on
-
-
- Closed
-
Activity
Please consider merging the pull request as the git-client-plugin now supports this.
Paul Eipper
added a comment - Please consider merging the pull request as the git-client-plugin now supports this. Code changed in jenkins
User: Mark Waite
Path:
src/main/java/hudson/plugins/git/GitSCMBackwardCompatibility.java
src/main/java/hudson/plugins/git/extensions/impl/SubmoduleOption.java
src/main/resources/hudson/plugins/git/extensions/impl/SubmoduleOption/config.groovy
src/main/resources/hudson/plugins/git/extensions/impl/SubmoduleOption/help-reference.html
http://jenkins-ci.org/commit/git-plugin/1840aff6a2422a771fba798a0b10595878eb7ff3
Log:
Merge pull request #348 from nKey/submodule-reference-new
[FIXED JENKINS-18666] Submodule reference
Compare: https://github.com/jenkinsci/git-plugin/compare/2c2dae0e23bc...1840aff6a242
Included in git plugin 2.4.1 released 26 May 2015
I'm confused as to how this option is supposed to be work: when calling `git submodule update --init` (with or without --recursive), it is going to init multiple submodules at the same time.
There's no sane value for the reference repository there unless you handcraft a repository with branches (which will then consist of a set of mutually-exclusive branches) from all needed repositories.
Am I missing something?
David Wagner
added a comment - I'm confused as to how this option is supposed to be work: when calling `git submodule update --init` (with or without --recursive), it is going to init multiple submodules at the same time.
There's no sane value for the reference repository there unless you handcraft a repository with branches (which will then consist of a set of mutually-exclusive branches) from all needed repositories.
Am I missing something? David Wagner you understood correctly.
A git repository (including a bare repository) may combine the content of multiple other repositories. In this use case, the user was willing to create a "mega-cache" repository which is the combined cache of all their submodule repositories.
Steps like the following would be used to create that "mega-cache" (in this example, the mega-cache will combine the git client plugin, the git plugin, and the credentials plugin into a single cache):
$ git clone --bare https://github.com/jenkinsci/git-client-plugin mega-cache.git $ cd mega-cache.git $ git remote add git-plugin https://github.com/jenkinsci/git-plugin $ git remote add credentials-plugin https://github.com/jenkinsci/credentials-plugin $ git fetch --all --prune
Ok, that's what I figured indeed but it seemed weird to me. Thanks for the background explanation, Mark Waite.
David Wagner
added a comment - Ok, that's what I figured indeed but it seemed weird to me. Thanks for the background explanation, Mark Waite . 
Needs the parameter to be available on git-client-plugin