Best Practices DevOps

Git Repository in Another Git Repository

Today, I’ll show how to keep git repository in another git repository. It may sound crazy and unnecessary. Yet, I’ve stumbled once on a need to do that during my career. So, I’ll share the way with the world. If you later find this article useful take a look at the disclaimer for information on how to thank me.

Why Store Git Repository in another Git Repository?

If you came across this article, you probably know why you need to do such a bizarre thing. Yet, for those who wonder why one might need to store a git repository inside another git repository, I’ll provide an example.

Suppose, your app needs to pull some code from a git repository (e.g. some script) and run it. So far, it seems like an easy use case. You test your app on a dev environment. Nicely, it has access to an org git repository hosting. Thus, there’s no issue to place your scripts in some git repository and provide repository url and credentials to your app. Now, suppose your app runs in an air-gapped environment for security reasons. In that case, the app obviously won’t have access to git repository hosting and must use a different solution. You might say, why require git access in the first place. It’s a rightful question for the apps you fully control. Yet, what if you use some 3rd party product which you cannot modify? I stumbled on such a use case while using AWX.

Real world use-case requiring storing Git Repository in another Git Repository

Simply put, AWX is a web app for managing ansible playbooks. Ansible requires an inventory of hosts to run the playbooks on. And such an inventory may come from a dynamic inventory script. AWX pulls this script from a git repository. That’s how it works and I can do nothing about it. Now imagine, AWX running in production air-gapped environment. How would you provide access from AWX to a git repository? Short things short, I came up with the solution of keeping an inventory script inside a bare git repository which resided in the code repository of AWX out of which its deployable artifact was built. Let’s see git commands I used to create bare git repository inside another repository.

How to store Git Repository in another Git Repository?

To achieve that, we’ll need to store the inner repository as files. This way, it can be source controlled just as any other data you want to store in git. Follow below commands to store repository (inner below) inside another git repository (outer below):

  • Create outer git repository:
mkdir /tmp/outer
cd /tmp/outer
git init
echo "i'm outer" > outer.txt
git add *
git commit -am 'outer'
  • Create inner git repository:
mkdir /tmp/inner
cd /tmp/inner
git init
  • make sample change inside inner:
echo "i'm inner" > inner.text
git add inner.text
git commit -am 'test'
  • Copy .git contents of inner repo to outer
mkdir /tmp/outer/inner
cp -r /tmp/inner/.git/* /tmp/outer/inner                                                                                           

Now, commit inner inside outer repository:

cd /tmp/outer
git add * 
git commit -m 'inner inside outer'

That’s it! You can now push outer repository, build a deployable artifact out of it and deploy it to production. Anyone or anything will be able to clone inner repository to get its contents. Try it locally:

git clone /tmp/outer/inner /tmp/inner_contents
cat /tmp/inner_contents/inner.text 
i'm inner

If you followed to this point, then you might really needed this to work as I did 🙂


That’s it about keeping git repository in another git repository. Feel free to share.

If you found this article useful, take a look at the disclaimer for information on how to thank me.

You can find below articles useful as well:

Best Practices

Git Tricks: git commit –amend + git force –push

Time has come to share useful git tricks and commands like git commit --amend + git force --push. We’ll show how using them helps us to keep git history stable.

If you later find this article useful take a look at the disclaimer for information on how to thank me.

Best Practices

Messed up your git history? Use git merge squash to clean it.


Have you ever found yourself in a situation when you made a lot of commits with messages like fix, more fixes in the dev branch? I did. It could have been that you stayed truthful to keeping git commits as small as possible. However, this rule applies only if your small commits were fully complete and tested. Let’s be honest, such commits most probably weren’t. Apparently, you just wanted to finish this never-ending task just to get it done.

Eventually, if you are lucky and patient enough, all these fixes lead to some working code. Would you merge it master? You could, but all these commits won’t pass code review. They shouldn’t, as this would make main branch messy as well. No one will be willing to understand these commits. Moreover, no one should ever revert to these commits, because they don’t represent a stable state in a repository history. So, what should we do?

Luckily, git merge --squash is the magic command which will help us to “squash” all these commits into one. The one we will merge to main branch