http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660The whole point of having to pull them separately is when they aren't necessarily needed. I have an application that has two optional dependancies, I include them in the vendors folder and if someone wants to run my unit tests they can git submodule init vendor/something and then update it themselves. I'm not incurring extra burden in my pulls to make it easier for someone who's too lazy to type two commands. http://ayende.com/4746/the-problem-with-git-submodules#comment7http://ayende.com/4746/the-problem-with-git-submodules#comment7Sat, 19 Feb 2011 18:40:56 GMTI started looking at submodule for two projects. One where we are going to switch to Git and one where the code was already in git. As soon as I found out that new developers needed to set up the submodule themselves after they pulled a repository I quickly gave up that idea. I agree, submodule is a good idea, but its setup needs to follow the parent repository. http://ayende.com/4746/the-problem-with-git-submodules#comment6http://ayende.com/4746/the-problem-with-git-submodules#comment6Mon, 10 Jan 2011 12:23:03 GMTKen, There are many reasons for people to want to get just the source. And my problems with submodules doesn't happen with 25 modules, it happen with 1, in the presence of branching. http://ayende.com/4746/the-problem-with-git-submodules#comment5http://ayende.com/4746/the-problem-with-git-submodules#comment5Mon, 10 Jan 2011 10:39:18 GMTI actually do not know how the download button works. I'd say that if you want to give people the ability to get the source without cloning (which makes them poor OSS citizens), then you'd host it somewhere and link from the Readme. Now I never said that submodules are terrific or anything. They do *work*, for some people (most people do not submodule 25 projects anyway), just not as smoothly as we'd wish them to. http://ayende.com/4746/the-problem-with-git-submodules#comment4http://ayende.com/4746/the-problem-with-git-submodules#comment4Mon, 10 Jan 2011 10:32:59 GMTKen, You are also ignoring the problem of what happen for people who are not using my build scripts. For example, people going to github to get the source by clicking the download button http://ayende.com/4746/the-problem-with-git-submodules#comment3http://ayende.com/4746/the-problem-with-git-submodules#comment3Mon, 10 Jan 2011 10:08:54 GMTKen, You might want to take a look here: [kerneltrap.org/mailarchive/git/2010/7/21/34801](http://kerneltrap.org/mailarchive/git/2010/7/21/34801) Not workable in the real world means that they introduce a huge amount of pain. As for a local change, what is this isn't really a local change, but part of a work in progress that I want to do in a branch? Or if I really want to make local changes to a remote repository that is part of my project? http://ayende.com/4746/the-problem-with-git-submodules#comment2http://ayende.com/4746/the-problem-with-git-submodules#comment2Mon, 10 Jan 2011 10:08:08 GMTquote: " they aren’t really workable in the real world" - a bit harsh. With the adoption rate of git, I'd say that probably at least one team have found it workable in a real world. As for your use-case, another quote - "Let us assume that I want to make a change that is local to just this project" - well then it is no longer really a shared resource, as it is manifested differently in every project using it, right? if you keep it simple, put shared projects in a shared location, and localized stuff (like the disclaimer) within your main repo, then from "principle of least surprise" things are simple and straightforward. Have your build-script copy whatever needed to the artifacts/legal folder, and you're done. http://ayende.com/4746/the-problem-with-git-submodules#comment1http://ayende.com/4746/the-problem-with-git-submodules#comment1Mon, 10 Jan 2011 09:53:26 GMT