In our git-svn managed project, we have 3 upstream projects that are all kept in native git repositories on GitHub. Since the source code of those upstream projects is under our control and changes frequently, our current solution, namely re-deploying the build artifacts to the super-project everytime we change something is quite cumbersome.
What I'd like to have is this:
parent project (git-svn):
--> submodule 1 (git)
--> submodule 2 (git)
--> submodule 3 (git)
That way, the source code for submodules 1-3 is compiled along with the sources for the super project, but I can push changes to submodules separately.
The question is: what happens when I git svn dcommit
on the parent project? Does this even work?
UPDATE Hm, I just set up a simple project structure, trying to resemble this scenario, and I receive this error message when trying to dcommit on the superproject:
a0301b11f3544a1e71067ff270eded65e4c8afbd doesn't exist in the repository at /opt/local/libexec/git-core/git-svn line 4775
Failed to read object a0301b11f3544a1e71067ff270eded65e4c8afbd at /opt/local/libexec/git-core/git-svn line 574
Any ideas/suggestions?
You can't do this, git submodules can't be pushed upstream into a svn repository via git-svn, it doesn't support this.
git-svn doesn't allow this, but if you have an access to your SVN repository server, you can install SubGit into it. It will created a linked Git repository for you, such that any push to it will be automatically translated to SVN revision and vice versa. After that you can add submodules to the resulting Git repository and work with the SVN repository using pure Git interface. These Git submodules will not be translated to SVN.
The translation is concurrent-safe and rather transparent (svn:ignores will be translated to Git ignores, EOLs to .gitattributes, tags to tags and so on).