I want to clone https://github.com/getyouridx/pychargify into my django project, and will need to pull updates from time-to-time.
Just for clarification, could I simply write a gitignore from the root directory of the django project e.g. .gitignore: pychargify/.git or are there other pitfalls I should be aware of?
Git has a feature for having a repository within another: submodules.
git submodule add https://github.com/getyouridx/pychargify.git
Be sure to read the entire documentation on submodules, as there as a few quirks involved with using them, and additional steps that need to be taken when doing a fresh clone of your own repository to initialize the submodules.
Also note that all submodule commands must be done in the root directory of your repository.
To have one git repo "inside" another, look at git submodules: http://git-scm.com/book/en/Git-Tools-Submodules
By making pychargify a submodule of your django project, specific revisions of your django project can be associated with specific revisions of your pychargify project. That can be really useful.
I'm not sure exactly what the dangers are of the approach you describe, but it doesn't pass the smell test for me. I would recommend using the Git feature (submodules) that is designed specifically for this type of thing.
Git automatically ignores and wouldn't even allow you to add any file / folder named .git. So you can just add a repo within your repo and work on it. You might have to ignore the inner repo folder pychargify however.
Submodules are needed when you want to share the repo with others who will be cloning it etc. If you are just looking at cloning the inner repo and working on your local repo with no one else involved or you don't want to have the repo elsewhere as well, you don't really need submodules.
Git subtrees
Git submodules is a common way, gaining much ground since introduced, in order to deal with the situation where one may want to add a project (repo) within another project (repo), as the other answers have correctly described.
Nevertheless, one could argue that the submodules way is not the only way and occassionaly not the proper way to go, depending on established workflows, for several reasons which I am not going to analyze and which are briefly mentioned in several pages such as this and this. The most important is arguably this:
When Git drops into conflict resolution mode, it still doesn’t update the submodule pointers – which means that when you commit the merge after resolving conflicts, you run into the same problem ...: if you forgot to run git submodule update, you’ve just reverted any submodule commits the branch you merged in might have made.
Of course in a perfect working flow this would never happen.
Another important reason is that the popular PyCharm IDE (when this is written; there is a very old issue for that) and possibly others as well do not fully implement git submodules and the coder will lose among others the nifty funtionality of the IDE displaying all changed lines in the submodule.
Therefore an alternative way to deal with this issue is to use subtrees. Notice that subtrees and subtree merging is not exactly the same thing, but this is again another matter. The excellent Progit book in its 2nd edition briefly covers the latter, but not a single reference for the former.
So in a practical example, in order to deal with the situation under concern, let assume a subproject to be consumed in a project:
$ git remote add subproject_remote (url)
# subproject_remote is the new branch name and (url) where to get it from, it could be a path to a local git repo
$ git subtree add —-prefix=subproject/ subproject_remote master
# the prefix is the name of the directory to place the subproject
$ git commit -am "Added subproject"
# possibly commit this along with any changes
If the subproject changes, to pull them into project:
git subtree pull —prefix=subproject subproject_remote master
...or the opposite (if changes are made in the subproject inside the project):
git subtree push —prefix=subproject subproject_remote new_branch
An analytical but rather clattered tutorial in this link.
This functionality has got some drawbacks as well, for instance a lot of people find the working flow cumbersome and more complicated, but again this depends on the particular established workflows.
Adding a folder containing a git project within another git project works as you might expect: there is no direct interaction between them and you can commit changes independently by working in one directory or the other. You can either have the "parent" project ignore the inner folder entirely or you can commit selected files from the child folder as if they were part of the parent project.
If you do the latter then when you modify a file it will be seen as modified by both git projects and you can manage those changes independently (commit the changes) by simply working in one directory or the other.
I'm assuming you are using the command line tools here, although I believe XCode 7 may understand the situation and display change annotations on the files as long as the files are seen as modified by one or both of the git repositories.
I find the procedure above to be simpler than dealing with submodules but others have commented on how to use those so you may want to compare.
