3 ms·

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

by mansr 16y ago

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.

sandGorgon 16y ago
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 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.
- pilif 16y ago
  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.
  - deleted 16y ago
    [deleted]
- brainlock 16y ago
  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.

by mansr 16y ago

sandGorgon 16y ago

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 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.

pilif 16y ago
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.
- deleted 16y ago
  [deleted]
brainlock 16y ago
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.