How to properly manage a git repo in a subdirectory, ignored by the parent directory, as its own project?

Question

I am looking to use Vagrant for a development project for laravel. To facilitate this effort, I am using this github project, Laravel4-Vagrant.

The vagrant configuration is managed as a git repository. Part of the Vagrant setup has a per-defined www directory which gets mapped to /var/www once the server is setup so you can just work with files inside the guest vm from the host vm directly. However, within this www directory there is a .gitignore file. This makes a lot of sense because you want to manage your vagrant setup and start from scratch with your app development, etc.

However, you start doing your application development and have your project sitting in this www directory. It would be nice to also manage this project in git, then you could deploy your app to another web server or a new vagrant installation. Because of the .gitignore file there is no way to use git on the files in this directory since the parent wants to ignore it.

I am not sure if git-submodules is the right solution here or some other special configuration.

---

More generically:

How can I create a git repo for a project, which ignores a child directory, but the files within that child directory (which are ignored by the parent) are managed at their own git repo?

Ideally, I should be able to package the parent up and the child up separately.

Would appreciate some generic explanation and some specific help to setup the project listed above as the example.

---

Edits:

There is no real requirement for structure, etc as long as the two projects can be maintained in separate repos and can either be deployed together or one their own (e.g., I can use my custom vagrant built to setup another dev/prod environment or I can deploy the laravel project to an existing deployment elsewhere). I would also consider other standard source version control systems that easily work together. Also, would it make a difference if the initial laravel repo was installed via git? using the template github project cited above, it does not clone a git repo for the initial install but uses the laravel installer.

Answer 1

From the root of the project, with a clean index:

1. git rm www/.gitignore

2. Add /www to your .gitignore at the root of the project. Might as well get rid of these lines while you're at it:

   /www/bootstrap/compiled.php
   /www/vendor
   

3. git add .gitignore

4. git commit

...and that should do it. You can now run whatever git commands you want inside www without interfering with the outer repo. Both repos can be cloned separately, though the vagrant config shouldn't work unless the inner repo is cloned in the right place of course.

Answer 2

Git submodules are, from your repositories point-of-view, a "link" to another repository. Use cases would include dependencies which are developed outside of your project. I personally would not use it to separate your project from your vagrant setup.

I have two ways I usually set up projects with vagrant. They may serve as a guide for you to decide what you are going to do.

Put the vagrant setup inside your project

When using a vm which is tied to exactly one project, I am putting the Vagrantfile and cookbooks together with all src files into one git repository.

The repository folder structure may look like:

myProject/src/
myProject/vm/

Within vm, one can find the Vagrantfile, the .vagrant folder (ignored by git) and provision files. Within the src. I put everything which would normaly live in the repository root.

This setup is handy if the vm is tighly coupled to the project. The vm does not need to be used if somebody chooses not to, but it's there. By splitting the dirs, one can filter the git log by directory and have a "clean" log of changes to the project and to the vm if needed.

A drawback would be that the files take a bit more space on the HD, but as they are only text and usually not that much, this doesn't really count.

You can of course put the Vagrantfile into your repository root together with the normal project setup and have a folder for your provision files.

Have a vm repository and project repositories

For this setup, the singular VM has it's own repository. The Vagrantfile points to places on the host system for synced folders.

VM --> vm/project-a --> dev-machine/project-a
   --> vm/project-b --> dev-machine/project-b
   --> vm/project-c --> dev-machine/project-c

The host system folders may not be there if the user has not cloned those projects. It could also happen that the user does not update the project repositories. Then they will get errors because changes to a project break the VM.

We used this setup in one company where we had many different projects all running on a bunch of identical servers. So, we needed only one VM to run all those projects.

After a short time, everybody was used to updating the VM if errors occurred. We also checked a Vagrantfile.dist into the repo. Developers had to copy it and create their own local Vagrantfile from it. They would change the synced folders to point to real project paths on their host. Also, they would need to remove projects they were not working with.

It would have been much worse if we created a VM for every project. Or, ship the VM as a single project and have everybody check out and develop with that project.