Keeping unrelated projects in a single repo is every bit as bad as keeping all the source code for one project in a single 500k-line C file. CVS modules are a nightmare to work with, and I consider the lack of such abominations a feature of git et al, not a shortcoming.<p>The author's straw man of a git repo per file is also quite unconvincing.<p>Git may have some shortcoming, but this is not one of them.
Did the upvoters actually read and understand this post and its errors and decide to up it just because it was an "interesting" boneheaded post?<p>Or maybe it is all the anti-TDD folks upvoting first and then maybe checking the whole thing actually makes sense? :)<p><i>Submodules</i>, if you find you must depend on external libraries at the repository level (for patching, perhaps).
> Checking out a Git repository involves downloading not only the entire current revision, but the entire history. So this creates pressure against putting two partially-related projects together in the same repository, especially if one of the projects is huge.<p>See git clone's "--depth" option. There are limitations to what you can do with a shallow clone, but you do not, in fact, need to pull down an entire history.<p>Regarding the rest of TFA, the author should look at git submodules, as already mentioned here in the comments. However, submodules should not be used without understanding their implications and limitations (it is worth searching the Git mailing list).<p>There are at least three alternatives to submodules I'm aware of:<p>1. git-subtree - <a href="http://github.com/apenwarr/git-subtree" rel="nofollow">http://github.com/apenwarr/git-subtree</a><p>2. gclient - <a href="http://www.chromium.org/developers/how-tos/install-gclient" rel="nofollow">http://www.chromium.org/developers/how-tos/install-gclient</a><p>This is part of so-called "depot_tools" used by Chromium and ChromiumOS, and can tie together subversion and git repos.<p>3. repo - <a href="http://source.android.com/source/git-repo.html" rel="nofollow">http://source.android.com/source/git-repo.html</a><p>This is used by the Android project.<p>The latter two are not really designed to be used outside of the projects for which they were created, but both are Python code so they can probably be adapted pretty easily.
The problem is not CVS or Git or SVN. The problem is fundamental and actually very widespread. Within a given semantic domain, one program, one database manipulated by one program, one OS process, we can enforce all sorts of useful guarantees, from consistency of the database to guaranteeing interesting and useful properties about the data to strong typing (in the program case) and so on. Once you leave the island, you are back in the untyped swamp of arbitrary code. Git makes progress by enforcing more interesting properties on a larger chunk of stuff than CVS, but nobody can enforce those interesting properties on the entire universe.<p>When you learn to see this problem, you start to see it everywhere; it's so fundamental and pervasive you can't hardly even see it.
Mercurial's subrepo is a pretty good stab at fixing this, IMO. It's unpolished, right now, in that it doesn't deal with some of the more complex scenarios well, but the idea is really getting there (and it works with SVN subrepos, too -- we have git in the works).
* _The DAG-based systems don't represent changesets that cross repositories. They don't have a type of object for representing a snapshot across repositories. _<p>* _Creating a tag across repositories would involve visiting every repository to add a tag to it._<p>These two, at least, are technically accounted for by git submodules, though they are a bit of a pain to use.
> <i>In the DAG-based systems, branching is done at the level of a repository. You cannot branch and merge subdirectories of a repository independently: you cannot create a commit that only partially merges two parent commits.</i><p>Please inform me, how can you ever possibly create a commit that is a "partial merge" from two parent commits? At some point, you had to explicitly choose what you wanted to merge or not merge, and you can do exactly that in Git, and I would certainly assume that you could do that in Mercurial and Bazaar too. Or am I missing something?
I don't get it. What prevents him from writing a simple shell/python/whatever script that uses a simple hash-table with tag associations for different repositories for synced checkout via git hooks?