On 28/02/13 19:55, Bertrand Jacquin wrote: > Another thing that can be done is a dumb repository using git submodule > : > > $ git init /var/tmp/e-core > $ cd /var/tmp/e-core > $ git submodule add http://git.enlightenment.org/core/efl.git/ efl > $ git submodule add http://git.enlightenment.org/core/elementary.git/ > elementary > $ git submodule add http://git.enlightenment.org/core/enlightenment.git/ > enlightenment > $ git submodule add > http://git.enlightenment.org/core/evas_generic_loaders.git > evas_generic_loaders > > Then to update all the repositories : > > $ git submodule update > > We can easily provide some dumb repositories for different kind of usage > so you will just need to clone the dumb one. Theses dumb repo should be > maintain manually.
Yeah, we thought about that, and also talked about it with leif that suggested it as well. I don't really like it. While it does make sense for efl, elm and evas_generic loaders as they might have actual dependency requirements, enlightenment has nothing to do with it. Also, people will have to maintain that repository which is quite a pain in the ass, and a good reason why to give up on this idea. When you run "git submodule update" it doesn't "update" the repositories according to upstream, but it's just a "local refresh" thing that updates the repository according to the state recorded in the aggregating repository, and not according to upstream. Someone would need to manually update that to make sure people have "good versions". If you consider how quirky submodules are for new git users, you understand it just doesn't worth it. -- Tom. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
