Ok, I leaned what git submodule is for, well at least I think so. Apparently its primary use to as a mechanism for tagging a set of repositories, see my post here, which starts here. What help the most was looking at the tutorial here.
The as it indicates in the Title my original goal was to have some way of combining multiple git-repos. git-submodule doesn’t really do that and there doesn’t seem any easy way to do it. But Daniel Barkalow provided me with the instructions below which did combine them with linear history which is just fine. I do not understand why it works and I also wonder how the instructions might be changed if there were multiple branches in one of the repository and I had wanted to get that history also? Anyway, questions for the future.
Ah, okay. I was assuming that you wanted them to maintain their original identities (so you'd send stuff off for each of them separately, for example). I think you can do what you want by doing: # Set up the new line: $ mkdir x; cd x $ git init $ touch README $ git add README $ git commit # Add a project "foo" $ git fetch ../foo refs/heads/master:refs/heads/foo $ git merge --no-commit foo $ git read-tree --reset -u HEAD $ git read-tree -u --prefix=foo/ foo $ git commit And repeat for all of the other projects. What's going on here is that you're merging in each project, except that you're moving all of the files from that project into a subdirectory as you pull in the content. The resulting repository has one recent dull initial commit, and then merges in each of the other projects with their history, with only the slight oddity that they don't go back to the same initial commit, and the merge renames all of the project's files. I think there may be a more obvious way of doing this (it's essentially how gitweb and git-gui got into the git history), but I'm not sure what it is, if there is one. -Daniel
After this post, Daniel came back with a nice explanation for what each line did, you can see the post here.