As described in ZNTA-770 , having multiple repositories is affecting our ability to do continuous integration, and to test changes which require api, server and client to be modified together ("synchronised pull requests").
Back in 2012, the idea of splitting these repositories was to allow them to follow different lifecycles, but in practice they always tend to be released together anyway (see for example Zanata 4.0.0-alpha-1), especially as we try to move towards continuous delivery.
We need to look at putting them all back in a single repository. This should make our release scripts far simpler, and avoid problems like server pointing to the wrong api snapshot, or changes in api breaking the server build.
could be used for this, but the resulting git history for individual files is not good (and existing pull requests would probably become modify/delete conflicts).
I think the best option for us is:
See http://www.nomachetejuggling.com/2011/09/12/moving-one-git-repo-into-another-as-subdirectory/ and https://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history/
can be used to merge pre-existing pull request branches (in this case, api has been moved to the directory api/, api/enunciate2 represents the 'enunciate2' branch for the remote 'api')
NB: This wiki page will become obsolete: https://github.com/zanata/zanata-server/wiki/Git-Submodules