0

I'm currently trying to come up with a version control strategy for moving our company’s code and document files from a centralized SCM (Perforce) to Git. The content in Perforce is just one large Depot where all the projects are stored, I want to break this up into multiple smaller Git repositories for a number of reasons.

The issue I have now is how can I index all of these repositories so they can be easily found. As far as I can tell, Git doesn't have any built in tools for managing multiple repositories.

I did find the git-submodule, but it sounds like that's for making a repository with content of other repositories, and I don't want to manage the content of various repositories but the repositories themselves.

Originally I was thinking about a flat file system on our sever:

/repos
   -repo1.git
   -repo2.git
   -...
   -repoN.git

and then just a git command to query this directory for all the repository names and a comment about the content (sort of like logging into the server, going to the /repos directory and running a git log). I was thinking I could make /repo itself a git repository (a repository of repositories) and then do exactly what I just said, but that seems so... un-git-y.

So my questions are:

  1. Am I missing any built git tools/features that are made to manage multiple repositories like this?
  2. Am I correct in my thinking that git-submodule is not what I'm looking for to help manage this?
  3. Are there any good strategies that you've seen for this type of set up?
Mike
  • 40,613
  • 26
  • 100
  • 171
  • 1
    The closest thing is probably submodules. You can have a (possibly empty) root repository that refers to all other repositories, which are still independent and can be cloned and worked on individually. Another option would be Google's Repo tool that's used for Android (but isn't tied to it), but I'd prefer submodules. – Magnus Bäck Jan 31 '14 at 19:31
  • 2
    Perforce have a tool that lets you keep all your code in the Perforce repository, but use git as the client. That way your developers get to use git, but your administrators have the convenience of a single repository to manage. – Bryan Pendleton Jan 31 '14 at 22:16
  • It's a simple lookup in a small table, a flat file is all you need here. `curl u://r/l | grep ^projecta`. – jthill Feb 01 '14 at 00:56

1 Answers1

0

If you want a pure Git solution, then you are looking exactly for git-submodule.

Especially when you say:

I was thinking I could make /repo itself a Git repository (a repository of repositories)

This is exactly what submodules are.

The parent repo would keep track of a single file - .gitmodules, which connects paths with revisions of other repos.

However in my experience I've come to the conclusion that Git submodules are not ideal, especially when you deal with inexperienced Git users. It could cause problems when switching branches or making changes in the submodules. Some GUI Git clients do not have full support for submodules.

But if you just want to track these folders, you could be OK with submodules.

Another way is to ignore such folders in the main repo and have separate Git repos in these folders. Git works perfectly in these folders, no matter they are under another Git repo.

This solution works very well for vendor libraries within an application project. And you could use a package/dependency manager to update them or just cd and git pull.

Haralan Dobrev
  • 7,233
  • 1
  • 44
  • 62