On Thu, Aug 28, 2014 at 01:44:18PM -0400, Marc Branchaud wrote: > Heiko also said this: > > On Fri, Aug 22, 2014 at 12:00:07PM -0400, Marc Branchaud wrote: > >> With relative-path submodules, the push's target repo *must* also have the > >> submodules in their proper places, so that they can get updated. > >> Furthermore, if you clone a repo that has relative-path submodules you > >> *must* also clone the submodules. > > > > That is not true. You can have relative submodules and just clone/fetch > > some from a different remote. Its just a question of how to > > specifiy/transport this information. > > I meant that more as a general guideline than some kind of physical law. > Sure, it's possible to scatter the submodules across all sorts of hosts, but > it's not a good idea. When it comes to relative-path submodules, pushing and > fetching submodule changes in the super-repo should just involve the one > remote host (whatever way that's determined). This keeps things tractable, > because otherwise your branch's changes are scattered among many different > hosts and you end up considering weird things like "this part of the branch's > changes are on host A but this other part are on host B, so let's record that > somewhere, oh but what if host B is down when I'm trying to fetch, but I know > that host C has the changes too so why don't I just fetch what I want from > there". > > It's a nightmare. It's infinitely better to treat a repository and its > relative-path submodules as an atomic unit, so that any remote that hosts the > repository also hosts the submodules. When pushing a branch with submodule > changes, expect to find those submodules on the target remote and update > them. Regardless of how the target remote is determined. Same thing for > fetching. It's just so much simpler to work this way. You are right, its simpler. But I would not say "better". Depending on your project it might be "better" to just fork some submodules. > So please, let's not try to specify submodule remotes per-branch or make that > info pushable. It's enough for a branch's local configuration to say that it > tracks fetch/pull refs on different remotes. The rest should flow from that. Why not? Git is all about flexibility. Of course if you organise your submodules in chaos you will get chaos. But consider this: You have this big project which consists of submodule (e.g. like Android with hundreds of submodules). Now you want to develop on something that involves just a subset of submodules, lets say two submodules. Now if someone just wants to publish a small change to some submodules you are demanding to setup a mirror of *all* submodules that are in this big project. That might not even be feasible depending on the projects size and the remote quota. Not to speak about having to first create a fork of hundreds of repositories. So in this situation we should support just referring some submodules to other places. Regarding transporting this information. If you ask someone to try out your change it should be as simple as possible. It should be enough to say. clone from there and checkout that branch (once recursive checkout and fetch for submodules is in place). So here we need a way to transport this configuration for a fork. Yes for a small project where its feasible to simply clone all submodules you can just say: please fork everything. But for bigger projects thats not necessarily an option. So we should at least give the users that option. Then its a matter of policy how you work with a project. I am not saying that everything for this should be implemented in the first steps but we should keep it in mind and design everything in such a way that it is still possible to implement such a kind of workflow later. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html