Git: Submodules are to hot. Subtrees are to cold. Just use fetch ?

Submodules and subtrees are too complicated… Sometimes you can just use git fetch to share code between repos.

Disclaimer: This post is EXTREMELY simple.  It is for begginers in git that want to create composite projects but don’t really want to dive into the labarynthine realm of submodules / subtrees. 

This post outlines an easy and simple way to share code from “project A” into “project B”, using “git fetch”, and leveraging the fact that git supports multiple remotes.  In the end, you’r “project B” will have two remotes: its own, and that of “project A”.  It will replicate the history of project A also (which is not necessarily ideal, but, thats the approach that we will go with – if you want REAL dependency management : use a real dependency manager / build tool like maven/rpm/etc).

This workflow for maintaining a composite git project:

1) Doesnt require custom subtree stuff
2) Won’t trip you up with new semantics in your git workflow
3) Is totally transparent : All history will be in your commit log and no where else.

Why bother posting a manual methodology for managing git based dependent projects?  Because I’m not sure there is a good git based tool for this yet.

A breif aside on the alternatives:

Submodules

“if you forget to update your submodule to the new version, it’s then quite easy to commit the old submodule version in your next parent repository commit – thus effectively reverting the submodule bump by the other developer.” – from http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/.

        Thus : submodules are really complicated.  At first glance, thats not a big deal, but over time, you can lose alot of code and lose commits when submodules arent managed properly, because of the fact that they descend into a detached state.

Subtrees

Subtrees aren’t part of the standard “git” that everyone has.   Its kind of strange to force people to have to set up a “special” git component just to use subtrees.  After all, subtrees aren’t really perfect either !

Since they duplicate the commits and code into a your super repository, they are actually quite similar to a fetch (correct me if im wrong here – im not subtree expert, but they really seem like little more than an source embedding tool with a little extra syntactic sugar). 

A simpler way to share code between projects: git fetch!

I know this is dead simple.  So simple maybe it doesnt even deserve a blog post. But… I bet somebody will find it useful.  After all, there are alot of folks using git out there and not all of them want to spend all day figuring out peripheral git utilities just to pull a few files into their superproject.

So here’s a dead simple example of how to feed code from one project into another using git fetch:

Lets say I have two repos: A community one and a private one.

I can easily pull from my community  into my private by the following workflow:

1. Create two repos (one called “community”,  the other called “private”).
2. Go into your community repo: git@github.com:my_name/my_community_repo.git
1. touch community_file
2. git add community_file ; 
3. git commit -m “first communal commit”
4. git push origin master # <– payload = 1 commit.
3. Go into your private repo:
1. git remote add community git@github.com:my_name/my_community_repo.git
2. git fetch community
3. git merge remotes/community/master 
1. NOTE: If you DONT want to put the commits in with the merge, you can run

   "git merge remotes/community/master --no-commit --no-ff"

4. git push origin master # <– payload = 2 commits.

You can see how it pans out here:

https://github.com/jayunit100/mock_community <– has commits from community repo

And

https://github.com/jayunit100/mock_private <– has commits from community repo + its own commit.

^^ If that looks like what you wanted, then you can (maybe) forget about using the git sub* tools and just read the man page for “git fetch”.

The downside

Okay so , what happens when your code diverges ?  You have to manually pull in the latest from your upstream repo and commit it.  Well… thats not so bad.  At least you know what you have to do and have the tools to do it in your head and in any old git distro.

Moral of the story 

Well, i guess if you want REAL dependency management : you can use a dependency manager like maven, gradle, pip, yum, or whatever.   From what I can tell, git wasn’t built to manage dependencies.  Until then – just fetch from different repositories and push those commits into your own repo 🙂
 
Remember that git really does a great job supporting multiple remotes!  So use them to your advantage 🙂