How to deal with repositories-within-repositories has been an ongoing question with git. Git's submodules are one way of addressing the situation, at the expense of adding a little more complexity to keep track of. The git site has a nice introduction to submodules.

The basic idea is to keep a reference to another git repository associated with a path on your repository. These references are stored in a file .gitmodules in the root of your repository (which is managed by git, so leave it alone). Some of the complexity comes in to play when cloning a repo which has submodules: you must explicitly git submodule init to create the .gitmodules file, and then git submodule update to clone the submodules.

How to deal with repositories-within-repositories has been an ongoing question with git. Git's submodules are one way of addressing the situation, at the expense of adding a little more complexity to keep track of. The git site has an introduction to submodules.

The basic idea is to keep a reference to another git repository associated with a path on your repository. These references are stored in a file .gitmodules in the root of your repository (which is managed by git, so leave it alone). Some of the complexity comes in to play when cloning a repo which has submodules: you must explicitly git submodule init to create the .gitmodules file, and then git submodule update to clone the submodules.

Here's a walkthrough of how I'll add a new vim plugin to my dotfiles repository (I have ~/.vim/ aliased to this repo's .vim/) using a submodule:

$ cd dotfiles/ $ git submodule add https://github.com/elixir-lang/vim-elixir.git .vim/bundle/vim-elixir 

After the submodule add, a git status would show that you've modified (or created) the .gitmodules file, with something like this:

[submodule ".vim/bundle/vim-elixir"] path = .vim/bundle/vim-elixir url = https://github.com/elixir-lang/vim-elixir.git 

It should also show .vim/bundle/vim-elixir as a new file. Git treats that path specially now: it's a normal directory on your file system (so vim loads it up normally), but git diff will treat it as a specific commit from its repository. When looking at diffs or logs for that path (e.g. git log -1 -u .vim/bundle/vim-elixir), git will show it as a one-line string like this:

Subproject commit 2d59d1d52a9bcf9342d42fa7d6b59e6a1aaa7b9e 

Updating to the latest version of the plugin corresponds to going into the submodule's repository and checking out a new commit, and then committing that to your repository:

$ cd .vim/bundle/vim-elixir $ git remote -v # note: the submodule repo's origin, not my repo's origin https://github.com/elixir-lang/vim-elixir.git (fetch) origin https://github.com/elixir-lang/vim-elixir.git (push) $ git pull # ... $ cd - # back to my repository's root $ git status # ... modified: .vim/bundle/vim-elixir (new commits) $ git diff .vim/bundle/vim-elixir # ... -Subproject commit 2d59d1d52a9bcf9342d42fa7d6b59e6a1aaa7b9e +Subproject commit d59784e7afbd0d55c501e40c43b57cbe6f6e04c2 $ git commit -m "update vim-elixir" .vim/bundle/vim-elixir 

How to deal with repositories-within-repositories has been an ongoing question with git. Git's submodules are one way of addressing the situation, at the expense of adding a little more complexity to keep track of.

How to deal with repositories-within-repositories has been an ongoing question with git. Git's submodules are one way of addressing the situation, at the expense of adding a little more complexity to keep track of. The git site has a nice introduction to submodules.

The basic idea is to keep a reference to another git repository associated with a path on your repository. These references are stored in a file .gitmodules in the root of your repository (which is managed by git, so leave it alone). Some of the complexity comes in to play when cloning a repo which has submodules: you must explicitly git submodule init to create the .gitmodules file, and then git submodule update to clone the submodules.