Best way to re-do a CVS repository with git?

I have a large CVS repository (1.5 GB without its history) that I'd like to convert to git, but I'm not sure about the right way to set it up. If I need to change the way I'm thinking about source code management, that's fine too, but here's what I have today in a single CVS repository:

MyProject
   Apps                 # Only apps people use this.
   Common               # Everyone uses this.
   Firmware             # Only firmware people use this.
   External/ProjectA    # Only app people use this.
   External/ProjectB    # Everyone uses this.
   External/ProjectC    # Only firmware people use this. This is 1 GB
of code by itself.

I manage this today with CVS modules, one for apps people and one for firmware people (and another CVS module with everything for people like me that work on both).

I initially thought I'd create separate git repositories for each piece, but I'm not sure how that would work when it comes to tagging an entire release (i.e. a tag that spans multiple repositories). Or how it would handle a git repository within a directory managed by another git repository.

What's the best way to set up something like this with git?

I think the subject would better read: "What is best way to represent multimodule CVS repository in Git?"

skillzero@gmail.com writes:

I think that such setup would be best managed by creating Git repository for each piece, and "integration" repositories, one for apps people, and one for firmware people, using submodule support in Git.

Tagging entire release would be tagging in "integration" repository, the one using submodules.

See also:
 * http://git.or.cz/gitwiki/SubmoduleSupport
 * http://git.or.cz/gitwiki/GitSubmoduleTutorial
 * http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
   aka git-submodule(1)

On Sat, Apr 19, 2008 at 1:23 AM, Jakub Narebski <jnareb@gmail.com> wrote:

Thanks for the info. git submodules seem like the right direction. But unless I'm misreading the tutorial, using submodules would require each user to know about and maintain every super module that might use each submodule. For example, if you had:

moduleA
	fileA.txt
moduleB
	fileB.txt
moduleC
	fileC.txt

super1
	moduleA
	moduleC

super2
	moduleB
	moduleC

super3
	moduleA
	moduleC

I commit a change in fileA.txt (in moduleA). I now have to commit moduleA to super1 and then commit moduleA to super3. Otherwise, super1 and super3 would still refer to the previous commit of moduleA. That's a good amount of extra work (I can imagine there may being dozens of super projects referring to a certain submodule).

But there's a more serious problem in my case because not all users have access to all repositories. For example, if I have access to super1, but not super3 (I may not even know super3 exists), I won't be able to update super3. Now super3 is in a weird state: it has moduleA as a submodule, but it refers to an older revision of moduleA. Somebody with access to super3 has to know that moduleA has changes that haven't been included in super3 and manually pull them.

Or am I just misunderstand how submodules work? It seems to me that the super module could use a more abstract link: the super repository would refer to a branch name (e.g. master). Then when I do a git pull from super1, it would see it contains moduleA on branch "master" and would pull down the latest "master" branch from moduleA without ever having to commit moduleA to super1 or super3.

This is probably harder than it sounds, but it would seem to eliminate the need to know anything about super modules (except initially when the super repository is created). I just commit to moduleA and the next time somebody pulls from super1 or super3, they get the change automatically.

skillzero@gmail.com writes:

[cut]

I don't know if using submodules is a right solution: git submodules are for more or less loosely tied projects. It is a solution which is worth considering. It allows for example developing some experimental feature in subproject, while superproject use stable, tested version of submodule.

Another solution is to merge subproject directly to superproject using 'subtree' merge strategy, like currently gitk and git-gui is maintained/managed in git.

Yet another would be to use something similar to Mercurial's fores, or one of earlier submodule implementations, namely git repositories inside working directories in other git repositories.

And perhaps you would have to roll your own scripts around git, so single commit would trigger commit in supermodule; that or write your own hook scripts to do that.

Unfortunately it seems like nobody interested in your plight... and I cannot help mych beyound that what I've wrote...