Examples are at the bottom.
I've been been using subtree in a fork of Git personally but can't (safely) use it at work with everyone else (still use submodules there).
This is going to be a problem for github for reasons I put in my blog a few months back: http://zbowling.github.com/blog/2011/11/25/github/
Because Github has their explicit, top down, a-fork-is-only-a-fork-by-clicking-the-fork-button kind of graph between projects, using subtree won't work easily with their online tools to do pull-requests and see the network graph of forks.
Basically my repo is going to have the histories of 7 different projects combined in one repo and from that single repo I will be pushing back changes to all 7 (and others versions of those 7). Github's pull request feature is going to have trouble with that concept because they make the invalid assumption of a single upstream.
There are work arounds for sure like pushing your changes to a staging repo before finally doing a pull-request upstream but that is cumbersome. I'll probably write a shell script to automate it.
I hear this kind of thing all the time, but I don't understand why. I've never had any problem whatsoever with git submodule. Can you elaborate a bit on what you mean by this?
Ever tried removing a submodule? Why is there no git submodule rm? (No, "it's confusing" is not a valid argument.)
If the pull fails (say, from the wrong protocol), you end up with a half-baked submodule. Impossible to move, impossible to remove, impossible to update unless you dive into the config.
Misspell the folder you wanted the submodule in? That sucks. Go delete it from two separate locations, and try again!
Sometimes I have deleted my entire repository and cloned it again to update the submodules just because I changed the .gitmodules file.
Note: This actually takes less commands than messing around with .git/config.
There is a horrible habit of people forking projects on github just so their submodule stay stable. It's broken.
> There is a horrible habit of people forking
> projects on github just so their submodule
> stay stable. It's broken.
I don't see how this is an example of how git-submodule is broken. If you want to use someone else's code, that is under someone else's control in your repository without creating your own backup of said code, then you're the one taking the risk by not creating said backup.
If the git-submodule is mission-critical to you then you should either:
1. Always keep a separate mirror of the 3rd party repo.
2. Mirror the 3rd party repo to a hosted location, so that your submodule can point to the mirror instead of the source (basically creating a caching layer under your control).
This is no different than the guy that keeps all of his email in Gmail, then complains because Google shut down his account that 'email is broken' because it's possible for this to happen.
Yes I do this and I hate doing it!
clone a repo to the target dir. Add it as a submodule. Decide to play with a branch of the submodule, so switch to that branch in the cloned repo. Then if i decide to work with that, update my submodules, otherwise switch back.
Is that sort of workflow available in subtrees? How do I do it?
Why must some other library/module be part of my project? Why not reference and maintain the external lib/mod externally? We've been doing that for decades. It seems a solved problem.
Bringing an external library within the fold of your project feels like unnecessary coupling.
Bringing other libraries into my project is beneficial because then my build system is able to wrangle those just as easily as my code. (And it's also simply useful in the case where I've written both modules but maintain a separation for whatever reason--one is an open-source project and the other is not, whatever--to be able to make changes to one from within the other, run the tests for the submodule, and push it up to staging or upstream, without having to leave my current project.)
After you have divided your project into independent modules you have agreed that the changes in these modules are going to have minimal impact on each other, then what exactly is the point of merging the history of all those changes?.In my use case that would actually create a bigger mess.
Now I think this could perhaps be useful if there are modules that I have forked from elsewhere and the fork is going to be used in my project only.Although even then I dont see any downside of using submodules.
The downside of submodules is lack of good commands .For example a command to check out a different branch of each of my submodules - the branch which is used in this project.This could be done using the -for-each tag but its not trivial.
EDIT:In this thread zbowling makes a great argument against submodules.
There is a horrible habit of people forking projects on github just so their submodule stay stable
I don't think you should ever want to bring unreliable external components, like a random github project that you aren't actively contributing to, into your tree like that.
Funny, I thought this was the beginning of an argument agreeing with me. :)
git submodule .vim/bundle/.vim-colors-solarized
ln -s .vim-colors-solarized/vim-colors-solarized .vim/bundle/
Different versions of your code could rely on different versions of the library (e.g. you update your code to a newer version of the library.) So which version of the library you rely on also needs to be version-controlled.
This gets even more fun when you have a second project that needs an incompatible fork of the same library.
So, to avoid duplicate commits, you'd either have to rebase the main branch or squash the commits before adding it back to the subtree (and lose history)?
“[Subtrees] are also not to be confused with using the subtree merge strategy. The main difference is that, besides merging the other project as a subdirectory, you can also extract the entire history of a subdirectory from your project and make it into a standalone project. Unlike the subtree merge strategy you can alternate back and forth between these two operations. If the standalone library gets updated, you can automatically merge the changes into your project; if you update the library inside your project, you can ‘split’ the changes back out again and merge them back into the library project.”
I guess I will have to get used to the idea that linking external repositories is harder than Subversion externals :) Which have serious limitations, I know, but at least they are so simple.