Question

I’m organizing our product’s source code into a bunch of different Git repositories. (And I’m new to Git). Some of them will use other repositories on the same server via submodules.

As I understand it, a submodule in Git is a pointer to a specific commit in another repository and is defined by:

• URL of the remote submodule (e.g. git://foo.com/git/lib.git)
• A subdirectory to clone the submodule’s repository into (e.g. include/foo)
• The commit ID we are referencing

The problem is that a URL is being stored in the repository as part of the commit when the submodule was added. What happens if the URL changes? The parent repository might have hundreds of commits – all with a submodule referring to the old URL.

For example, suppose I store repositories Super and Sub in git://PrivateCompanyServer/repositories/*. Super refers to Sub via its gitmodules file: git://PrivateCompanyServer/repositories/Sub.git. Several developers make hundreds of commits to Super – just about every commit in Super has a snapshot of gitmodules with that URL in it. Several product releases are tagged and all kinds of branches have the URL in gitmodules. Now, suppose PrivateCompanyServer crashes and we move the code to another server. Or we reorganize the directory structure on PrivateCompanyServer. Or whatever. Now we have hundreds of commits in Super referring to the Sub repository at the old URL which doesn’t exist any more. Obviously, the gitmodules file can be corrected at the head of development branch and we can move on there. But there will be all kinds of old commits that we may have to go back to for maintenance reasons and they will all refer to the old URL that won’t work any more. How to handle that?

Obviously this could be solved by rebasing / “rewriting history” so that all gitmodules files in the repository have the new URL but I think this is not an option because just about every commit in Super would get a new commit ID. Everything referencing Super, including “Super-Super” projects using Super as a submodule and local developer repositories would all break – correct?

So what’s the best way to handle this? If you store a collection of repositories on a private company server – some of which refer to other repositories via submodules – what do you do when the server changes names – therefore invalidating the old URLs in gitmodules files?

The only workaround I can think of is to make “lots of branches” from every commit way back in history, just to hold the corrected gitmodules. Seems like that will make a lot of clutter and be cumbersome. Seems like there must be a better way – surely I’m missing something?

Answer 1

As long as you don’t run git submodule sync, the value in .gitmodules won’t affect the submodule path in a given checkout beyond the first time the submodule is initialized (after that, the path for the submodule is kept in the .git/config file).

So you can just change the path in the checkout once (using git submodule sync on a commit with the updated path), and it will persist without issue.