As you mentioned, QB only adds the "origin" remote repository, then how is the extra remote added? Also have you tried to clean the configuration when this happens?

We add another remote repository with a command step. The working directory is set to the repository and we execute `git remote add ...` command there.

Cleaning it up indeed fixes the issue, but the URL to the remote repository is provided in a run dialog of the configuration by developers (multiple different repositories are added as a remote this way). There shouldn't be a need to clean the configuration at all. It's a bug, as `git fetch` command used internally in QB has a different scope (all remotes) than the defined repository (only one remote).

In my opinion this either should be fixed, so we could compensate for the lack of functionalities with workarounds, or git repositories should support multiple remotes.

The "--all" option is added to fix issue QB-2320. QB manages its cloned repository internally and user should not hack to add additional remote to it in normal cases. Any reason you want to do that?

The `--all` parameter is not needed to fix issue QB-2320, as the `--all` parameter is needed to fetch all remotes, not all branches (see: https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---all ). To fetch all branches from a remote, a `git fetch ` command should be used, e.g. `git fetch origin` or even `git fetch` in this case. There seems to be a lack of understanding of how git works. Note that when you are fetching changes from a remote those are not merged to the local branches, but are fetched to the remote refs. each remote has its own ref namespace, as well as your local branches, tags, and so on. The directory structure looks like this:

.git/refs
|-- heads
| \-- master
|-- remotes
| \-- origin
| |-- HEAD
| |-- bugfix
| |-- fix
| \-- master
\-- tags
  \-- 1.0.0

So, when you run `git fetch`, you get changes from the remote in the refs/remotes/origin directory. To have the changes on your local branches (refs/heads), you have to merge the changes from the remote branch to your local branch, e.g. `git merge origin/master master` OR use `git pull` that does both operations for you (fetch and merge). The `--all` parameter result is only that it fetches changes from all remotes if there is more than one remote added to local repository, and without adding the remotes like we do, using command step, the results of `git fetch` and `git fetch --all` are the same, as there's only one remote by default.

Example of running git fetch on a repository locally (I've obfuscated potentially sensitive data) WITHOUT `--all` parameter:

$ git fetch
remote: Counting objects: 21360, done.
remote: Compressing objects: 100% (7026/7026), done.
remote: Total 21360 (delta 14314), reused 19603 (delta 13070)
Receiving objects: 100% (21360/21360), 36.63 MiB | 1.94 MiB/s, done.
Resolving deltas: 100% (14314/14314), completed with 1865 local objects.
From ssh://url.of.our/repository
   c9b7cf781ff..786fa0992b2 master -> origin/master
 * [new branch] fix/fix-something -> origin/fix/fix-something
 * [new tag] 1.0.0 -> 1.0.0

Once the fetch is finished, you can calculate changes between all branches residing in the remote.

See also: https://git-scm.com/docs/git-fetch

And yes, we do need that because we have a huge project that requires interactions between multiple repositories that are used as remotes. Since there's no option to add more than one remote to the repository directly in the QuickBuild configuration, we have to "hack" it (to be honest, it's not a hack; we simply want to use git remotes like they are intended to be used and QuickBuild doesn't provide us this possibility, so we have to do it through command steps).

In summary:
1. You do not need `--all` parameter to fix QB-2320, so it can be removed. It would fix our issue.
2. It would be best if QuickBuild could handle multiple remotes natively, so we wouldn't have to manage them using command steps.

This is a very detailed explanation. Thanks a lot!

Following your suggestion, I verified that "git fetch" does able to get all branches/tags of the origin remote, and has made the changes in QB 9.0.12:
https://build.pmease.com/build/4901

OTOH, we'd rather not to add additional options for multiple remotes to complicate the repository definition, as this seems like a rare case (at least not hearing about this requirement from other users till now)

Great! Thank you for solving this issue. As for multiple remotes for the repositories, I think it's fine for us, we already have a way around it in place.