2

I want to nest 2 git repos. I have been reading into submodules and for a while i thought it was great, I think I may want something else. Here is my situation:

First I think I should mention that all of my servers host websites and are setup in a staging.domain.com and domain.com (live) pattern.

In each server I have a parent repo that is a website and a child repo which it my core library. I need my core to be the same on all of my servers but the website repos will all be unique to the server where they live. I want to write changes to the core, push to all staging domains simultaneously, then do some quality assurance, and push to all live servers.

I originally though that submodules would meet my needs but the issue I have with them is that I need the cores to update all at once. If I use submodules my core will update but won't take affect until the parent website runs git submodule update and git commit.

I figure why not just use a gitignore to ignore the folder that the core is in and treat them like they're separate entities. Has anyone else done this? What problems will I run into? Do you have any better suggestions?

Thank you in advance.

Rhett N. Lowe
  • 97
  • 8

3 Answers3

2

It seems you might benefit from a post-receive commit on your staging server, on which you could:

  • push your updates to a bare repo core
  • trigger the git submodule update for all the staging sites
    • cd to one server site /path/staging/site1
    • GIT_DIR=/path/staging/site1/.git WORK_TREE=/path/staging/site1/.git git submodule update
    • repeat for each site

The idea would be:

  • one push
  • multiple updates
  • keeping the advantage of submodule (ie, recording the exact version of core your site is using)
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

Instead of submodules you can use git-subtree (Sample of usage)

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • this idea seems interesting I am going to read the tutorial tonight. :D – Rhett N. Lowe Nov 28 '12 at 01:42
  • I like this article and I think this would best fit my needs. Thank you :D though, I think the comments of Luciano and Psi, at the end of the "Sample of usage" link, were very useful too. They said the main difference between the .gitignore method and subtree implementation is, to clone the project, one would first need to know that there are actually two projects. If that is the leading benefit I would rather use .gitignore for it's simplicity. Since this is a private project, no one will download it without first knowing its duality. – Rhett N. Lowe Nov 28 '12 at 02:56
0

It depends on whether you want "git status" on the parent repo to return that the repo is clean. If you can live with "git status" on the parent repo returning something like "Untracked files:... core-libraries/", then you can just have the core-libraries repo as an untracked child of the parent repo.

Git really doesn't care about untracked files & directories.

Mark Leighton Fisher
  • 5,609
  • 2
  • 18
  • 29