How do I fork multiple projects into one repository with git?

Question

I have a 3 projects I'd like to fork. They're all related to each other - changing one will likely require a change to another. Because they're all related, I'd like to create 1 repository for the forks, while maintaining the ability to pull down updates from each original.

How would I setup my git repository?

These are preliminary thoughts so I wouldn't be surprised if this is crazy/stupid. Is it?

Laflam

Could you just elaborate on why you want a single repository for your 3 distinct but related projects? – Mcbroom

I mean: what are you trying to achieve? Keep in mind that git is completely different from SVN or CVS for example... – Mcbroom

Rather than building each separately (and in the correct order) I'd like to make them part of the same build process. Since they all have to be within one context for this, one repository makes sense to me. Any other idea's? Also, I intend to have my own projects (which are dependent on these) within this context. – Soil

I probably should have indicated I'm using a static language (c#) – Soil

How are you building them? Visual Studio? You have 3 separate solutions? Or 3 projects within the same solution? – Mcbroom

You can always use "git remote add <name> <url>" to add more repositories as source. – Feola

Answer 1

You can always use "git remote add <name> <url>" to add more repositories as source.

Chemnitz

How would I fetch/merge the sources for only files in a certain directory. (That was hard to explain). To be more explicit: If I have folders "proj1" and "proj2", and remotes for each respectively, how do I tell the fetch on remote proj2 that its source root is /prog2? – Soil

subtree merge... or submodules – Feola

Answer 2

You may be interested in git-submodule functionality. Quote from here:

Git's submodule support allows a repository to contain, as a subdirectory, a checkout of an external project. Submodules maintain their own identity; the submodule support just stores the submodule repository location and commit ID, so other developers who clone the containing project ("superproject") can easily clone all the submodules at the same revision. Partial checkouts of the superproject are possible: you can tell Git to clone none, some or all of the submodules.

Pulsometer

Looks like creating a sub-module will treat each project as independent. Unfortunately, I'd like all of them to be merged. On the man page for sub-module (thanks for pointing me here) it suggests using remotes and the "subtree merge" strategy. I'm gonna look deeper and report back. – Soil

This is the updated link for the git-submodule documentation: git-scm.com/book/en/Git-Tools-Submodules – Copyboy

Using submodules make sense for me, but I've made some changes in the code of submodule repo. How do I push my changes of submodules to my repo? – Impenitent

Answer 3

There's one possibility I've never tried "for real" but that might work well.

Let's say you have three projects creatively named Proj1, Proj2 and (guess it) Proj3. Let's also say that all or some of them depend on external libraries, for example one called Lib1.dll and another called SuperLib.dll.

First, for the folder structure, I'd do something like:

MyCode\
    build_all.bat
    Docs\
        [...]
    Libs\
        Lib1.dll
        SuperLib.dll
    Proj1\
        [...]
    Proj2\
        [...]
    Proj3\
        [...]

Then you would create one repository on each of the ProjX folders:

cd \MyCode\Proj1
git init
cd \MyCode\Proj2
git init
cd \MyCode\Proj3
git init

Then you would create a repository for the whole thing:

cd \MyCode
git init

The contents of this repository, for git, would be the Libs folder and its contents, the build_all.bat build script, and 3 subprojects.

So once you change your source code, let's say Proj1\Main.cs, the whole thing wouldn't see the modification. You would have to git commit on Proj1, and then you would go to the whole thing and then git commit it (now git will be able to see that Proj1 has been modified).

Using this method, the history of the whole thing would simply state when the ProjX were modified, but it would not directly keep track of individual files. Howver, as expected, the repository on ProjX would keep track of every file, as usual.

If you give it a try on a "real project", let me know the results!

Good luck!

Mcbroom

hmm, how will the git command know the difference between "the whole thing" and each sub repo? I suspect it might get a bit confused. Have you tried repo within a repo before? – Soil

It won't get confused: when looking for the repo, git will look on the current directory; if there's no ".git" directory inside, it will go up one level, and look for the repository (".git" directory) again, and this until it finds the first repository. So, you are safe. – Mcbroom

Answer 4

I think I should be using the subtree merge strategy. I'll have to actually try it out and see if it works well. I'll mark this answer as accepted if this turns out to be a good approach.

In the mean time, I'm still open for suggestions.

Laflam