Hacker News Reader

Comment by mansr | Hacker News Reader

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.

The author's straw man of a git repo per file is also quite unconvincing.

Git may have some shortcoming, but this is not one of them.

View on HN

not really. The problem is the way that projects are dependent on other projects. It is especially illustrative, if you use a package manager like apt-get. Installing something pulls in tons of other libraries/dependencies.

When you want to build something, you would want to build against their dependencies.. which you would want to tag in some manner.

For e.g. v1.0 of ProjA needs v0.8 of ProjB and v3.2 of ProjC. A nice example is NodeJS that needs The GoogleV8 engine. Take a look at the number of changesets that are simply managing revisions of V8 inside the NodeJS tree (http://github.com/ry/node/commits/master/deps/v8)

In an ideal world, you could have tagged a version of NodeJS source code with a particular version of V8 (which lives in a different repository), all under the same directory structure.

If v8 was available as a git repository, node could have gone the submodules route which works perfectly and is solving the exact problem the parent article is talking about.

To stay with node/v8, you would add v8 as a submodule and check out a specific revision or tag. The parent repository (node) would keep track of that revision and whenever you clone the parent, you'd be able to fetch the submodule and check out the correct revision.

If you want to update v8, you cd into the v8 dep directory and check out the newer tag. The parent repository will see this and offer you to commit that change to the submodule as a commit of the main repository.

We're using this facility internally with some projects, sometimes adding internally developped modules as submodules, sometimes adding public libraries.

Public libraries as submodules is really cool as you can use git's awesome merging features to keep around modifications you made to said libraries even if you update the target library.

I'm having a bit of difficulty at explaining the concept, but once you do it, it's simple and beautiful.

If you use git submodules, what you do is exactly like tagging. An example from a project I'm working on:

at some point I want to add a submodule for a dependency I need

  $ git submodule add http://github.com/fictorial/redis-node-client.git deps/redis-node-client

this produces a commit with the following diff:

  diff --git a/.gitmodules b/.gitmodules
  new file mode 100644
  index 0000000..1695499
  --- /dev/null
  +++ b/.gitmodules
  @@ -0,0 +1,3 @@
  +[submodule "deps/redis-node-client"]
  +       path = deps/redis-node-client
  +       url = http://github.com/fictorial/redis-node-client.git
  diff --git a/deps/redis-node-client b/deps/redis-node-client
  new file mode 160000
  index 0000000..5050251
  --- /dev/null
  +++ b/deps/redis-node-client
  @@ -0,0 +1 @@
  +Subproject commit 505025187faf3cf7a211f5e6bfd261e45bd0b1dc

Later, when I want to update the subproject to a new revision, i just

  $ cd deps/redis-node-client
  $ git checkout v2.0 # or whatever
  $ cd ../..
  $ git diff

    diff --git a/deps/redis-node-client b/deps/redis-node-client
    index bdbfb96..a98a74b 160000
    --- a/deps/redis-node-client
    +++ b/deps/redis-node-client
    @@ -1 +1 @@
    -Subproject commit bdbfb96293f868dc01917a38af2dc4b66dd86157
    +Subproject commit a98a74b71c1ad90f15c58bb904d17906689c85f5

From the point of view of the parent git repository it only updated the pointer to point to another commit.

Reply on news.ycombinator.com