I'm having the same issue. The repository in the workspace only contains the alphabetically first remote name (I used "gitolite" and "zdc" - only "gitolite" appears).

Cloning the remote Git repository
Cloning repository ssh://gitolite@XXXXXXXXXXXXXXX/sandbox_derhasi
git --version
git version 1.7.10.4
Fetching upstream changes from gitolite
Fetching upstream changes from zdc
ERROR: Problem fetching from zdc / zdc - could be unavailable. Continuing anyway.
hudson.plugins.git.GitException: Command "/usr/bin/git fetch -t zdc +refs/heads/master:refs/remotes/zdc/master" returned status code 128:
stdout: 
stderr: fatal: 'zdc' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:772)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:738)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.fetch(CliGitAPIImpl.java:160)
	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1023)
	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:941)
	at hudson.FilePath.act(FilePath.java:787)
	at hudson.FilePath.act(FilePath.java:769)
	at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:941)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1113)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:573)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:462)
	at hudson.model.Run.run(Run.java:1404)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:238)

I tried to find the specific lines of code in github, but as I'm no java guy, I really did not get anything
Would be great someone could fix that.

I believe the intended workflow for this use of the plugin was that multiple git remotes could contribute changes to a single Jenkins job. That Jenkins job would merge the changes from all the remote repos together, then if the job was successful, it would push the changes to a single central repository.

Since only one remote now seems to be added to the Jenkins repository, that workflow won't work until this bug is fixed.

Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/hudson/plugins/git/GitSCM.java
http://jenkins-ci.org/commit/git-plugin/4e23a5cdb3d22784ec6daf45f68edcf5d72c4543
Log:
[FIXED JENKINS-16914] fetch by URL, not by remote alias (that may not be set)

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Nicolas,
do I understand that "fix" right: instead of providing an alias you use the URI directly, so no specified alias is set?
If so, we might get problems with functionality that relies on a given remote alias. For example the "git publish" plugin uses a remote alias to push specific branches to.
In that case, wouldn't it better to ensure, the given specification was set as remote alias. I currently see the method GitClient:setRemoteUrl() that could help. But I'm not really sure, as I do not get the whole architecture yet.

Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/hudson/plugins/git/GitSCM.java
src/main/test/hudson/plugins/git/SubmoduleCombinatorTest.java
src/test/java/hudson/plugins/git/AbstractGitTestCase.java
src/test/java/hudson/plugins/git/GitSCMTest.java
src/test/java/hudson/plugins/git/TestGitRepo.java
http://jenkins-ci.org/commit/git-plugin/128f715dbae13ceb54ad36d38b584e3e1b309d26
Log:
[FIXED JENKINS-16888] compute ObjectId before checking isCommitInRepo
added unit tests to cover

• fetch from multiple repositories JENKINS-16914
• merge basic scenario

@derhasi you're right, I just restored the initial setup, but this could be a valid improvement.

Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/hudson/plugins/git/GitSCM.java
http://jenkins-ci.org/commit/git-plugin/5e898848a12a4923b7d882bdab0a31cd12ee9c44
Log:
JENKINS-16914 set remote.<remoteName>.url before fetch

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

The issue does not seem to be fixed in git-client 1.0.3, even though the submission 130be9a0c15a953c4c7ea3e3e170e1583939d2d1 is included in 1.0.3.

I defined a job with two repositories, one named git-protocol and the other named local-file-system. When I execute the job, the console output reports:

Started by user anonymous
Building on master in workspace /var/lib/jenkins/jobs/bin-multi-2/workspace
Checkout:workspace / /var/lib/jenkins/jobs/bin-multi-2/workspace - hudson.remoting.LocalChannel@192a97b
Using strategy: Default
Cloning the remote Git repository
Cloning repository git://markwaite2.markwaite.net/git/bin.git
git --version
git version 1.7.10.4
Fetching upstream changes from git-protocol
Fetching upstream changes from local-file-system
ERROR: Problem fetching from local-file-system / local-file-system - could be unavailable. Continuing anyway.
hudson.plugins.git.GitException: Command "git fetch -t local-file-system +refs/heads/:refs/remotes/local-file-system/" returned status code 128:
stdout:
stderr: fatal: 'local-file-system' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:772)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:738)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.fetch(CliGitAPIImpl.java:159)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1023)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:941)
at hudson.FilePath.act(FilePath.java:852)
at hudson.FilePath.act(FilePath.java:834)
at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:941)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1113)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1256)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:590)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:495)
at hudson.model.Run.execute(Run.java:1502)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Seen branch in repository git-protocol/HEAD
Seen branch in repository git-protocol/master
Commencing build of Revision 31ea928f9fc14022855618fac3621f10ecad2cf8 (git-protocol/master, git-protocol/HEAD)
Checking out Revision 31ea928f9fc14022855618fac3621f10ecad2cf8 (git-protocol/master, git-protocol/HEAD)
No change to record in branch git-protocol/master
No change to record in branch git-protocol/HEAD
[workspace] $ echo hello world
hello world
Finished: SUCCESS

After installing a locally compiled copy of the git-plugin (1.3.0-SNAPSHOT (private-03/02/2013 05:29-mwaite) from the latest source code ( 9625801c185976562467a016e9d6998227c08f41 ), I confirmed this is fixed. The 1.3.0 release of the git plugin should resolve this issue.

My mistake for reopening the issue. I've confirmed it is resolved in the most recent source code of the combination of the git plugin and the git-client plugin. The current git-client release contains the fix. The next git-plugin release (likely 1.3.0) is expected to include the fix.

Confirmed fixed