Combine multiple .git repositories while retaining file based commit info

Coming from CVS we have a packages directory, which contains single .git repositories for each package.

Sadly, these are not as independent as the original CVS owners thought, so usually they are all checked out together and combined as a whole package into whatever versioning system you happen to use as a developer.

Combining multiple git repositories and http://progit.org/book/ch6-7.html already told me how to combine them all into one .git repository, so instead of:

packages/intranet-asus-client/.git
packages/intranet-timesheet/.git
packages/intranet-core/.git

it looks like

packages/.git
packages/intranet-core (without .git, and so on).

git log in packages shows me the whole commit history (great), yet what is missing is:

1. File based git history like git log --pretty=oneline -- intranet-core/intranet-core.info. It only shows me the commits which I made in the combined repository (meaning in /packages/.git)
2. No branches or tags. I have a hunch that I would have to create a branch in /packages/.git for each branch present in /packages/acs-kernel/.git and so on. But how about tags?

Or is this one of those great examples where submodules would really be helpful? Sadly, this means for us (as we do regular client patches to packages) that we would have to fork (we use g开发者_StackOverflowithub....) every packages .git remote repository into a private one and use our own client branches there. Though this would be awesome for github (more money), it is less convenient for us.

Is there a solution for our problem, maybe with scripts running series of git commands to correctly pull the branches together and more importantly redo all the commits in the new packages directory with timestamp and author, so it appears as if the commits where done there all along instead of the subtrees? Or do I just use git log in a wrong way ?

You might want to investigate gitslave (http://gitslave.sf.net) which provides CVSish recursive superproject management in the git framework. It is much simpler and easier to use that git-submodules, but has some drawbacks (which you would not notice coming from CVS). Unlike git-submodules, gitslave does not take over your repository so you can use a mixture of legacy and gitslave commands. One use can always use gitslave another can always use pure git, and a third can use a mixture back and forth.

Once you set up gitslave, you can create a branch or a tag on all of the repos in one simple command, and switch branches, checkin, push, or do whatever you want.

It currently will probably not give you the file history that you want without work on your side, but that is something that could be added (patches welcome :-).