tags:

views:

187

answers:

4

I have a main repo (repo 1) that I work with. I have another repo (repo 2) that needs to fit into the first one and I'm not sure how I could have them both in the same folder. The idea is that I have a standard codebase that I need in each project - yet each project is it's own git repo.

/project
    /.git(repo 2)
    /.git(repo 1)
    /repo_2_sub
        /repo_2_sub_sub
            /repo_1_sub_sub
    /repo_1_sub
        /repo_1_sub_sub
        /repo_2_sub_sub

None of the files overlap - but some of the folder structures do. So sometimes certain folders from one repo will be in the other repo.

How can I work so these two repositories build the complete codebase?

UPDATE

Both git repos exist in the same root project folder level. They cannot be submodules since they cross back and forth through each other as shown above. They are not separate folders.

UPDATE 2

Wait, maybe this is easier than I thought. Can you clone a standard codebase repo and then create a new branch that is your project and then just keep merging that branch with the codebase repo each time it changes?

+2  A: 

Use git submodule

Update:

The standard code base that needs to be a part of all the repos has to be a seperate distinct git repository.

git submodule add <repo_nick_name> <repo_path>

will add that repo to this one. On cloning and pushing, only the .gitmodules file and the hash at the repo will be pushed/cloned.

git submodule init

and

git submodule update

respectively initializes and updates the remote submodule repos.

For detailed info, check the git community book documentation on git submodules and/or scot chacon's screencast on the same.

Lakshman Prasad
The problem is that they are projects in the same base directory.
Xeoncross
That shouldn't be any problem. submodules exist in the same folder as the module.
Lakshman Prasad
A: 

This has already been answered several times, e.g.:

Makis
No, those are subdirectories which can be handled with git submodules. I have two projects which must exist at the same level.
Xeoncross
+1  A: 

Edit: In order to have two .git directories, when you init them, there would be some extra work. When you init, do:

git --git-dir=.git1 --work-tree=. init
git --git-dir=.git2 --work-tree=. init

Now you have two git dirs in the same directory. Not very pretty. At this point, make sure that you have .git1 and .git2 in both .gitignores, since they aren't ignored by default. Additionally, every git command you run must also have the --git-dir argument to specify which repository you're interacting with. You could setup aliases for that.

Since they're in the same base directory and submodules won't work, you could put '.gitignore' files inside both '.git/info/exclude' directories. Putting them in .git/info/exclude makes sure that the other repo doesn't pick up the exclusions.

It may take some maintenance if the two repos differ by a finer granularity than folders, but if you specify in each .gitignore the files that belong only to the OTHER repo, it should work.

See: gitignore

bobDevil
You can't actually have two `.git` folders - I just put them there to show what I *think I want*.
Xeoncross
Well, you can, it just takes some extra work. See my edit.
bobDevil
Crazy man. I don't think I'll go this route since it seems like such a hack. Plus, it would be a pain to setup a bunch of team installs like this. Awesome to know it works though!
Xeoncross
+1  A: 

Wait, maybe this is easier than I thought. Can you clone a standard codebase repo and then create a new branch that is your project and then just keep merging that branch with the codebase repo each time it changes?

You could do that. I have also a project where I'm doing it like this. Most of the code is the same for all subprojects. I create a new branch for every project to keep the files that only belong to that project separated. I regularly merge the master branch into the other branches.

You could also create clones of the main repository. Then you would just merge the changes from the origin/master branch into the master branch in each of your projects.

Tomas Markauskas
It sounds like this is the easiest way to handle something like this since you don't have to explain a complex setup to each team member and for each project. Plus it seems less pron to error.
Xeoncross