{"thread":{"id":"25999","subject":"how to have real (existing) submodules?","startedAt":"2010-12-08T20:58:46Z","lastAt":"2010-12-08T22:25:09Z","messageCount":2,"participants":["Oliver Kullmann","Seth Robertson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"157628","messageId":"20101208205846.GW29789@cs-wsok.swansea.ac.uk","threadId":"25999","inReplyTo":null,"subject":"how to have real (existing) submodules?","fromName":"Oliver Kullmann","fromEmail":"o.kullmann@swansea.ac.uk","sentAt":"2010-12-08T20:58:46Z","receivedAt":"2010-12-08T20:58:46Z","isPatch":false,"sender":{"key":"o.kullmann@swansea.ac.uk","avatar":null},"body":"Hi,\n\nI have the following organisational problem:\n\nDue to access restrictions, privacy, communication problems etc.\nI need to have independent git repositories for various projects\n(for example working on a scientific paper --- tossing the repos\nas tarballs around is really great, and it works also for those\nwho do not want to use git). There repositories exist all at various\nlocations, often just local repositories, without internet access\n(though some are on Github).\n\nThis creates obviously the problem of carrying them around (especially\ngiven that certain places don't have Internet connection, and data\nneeds to be transferred via memory sticks).\n\nI thought that \"git submodule\" would solve the problem, but now\nI realised that these submodules are not \"real\", but they only contain\na bit of meta-data (this should really be said directly in the documentation).\n\nSo my hope, that I can have one super-repo, where I say, e.g., \"git submodule foreach pull\",\nget the full super-repo, copy it on a memory stick, and then by pulling from\nthat copy I get everything into another super-repo, from which I distribute the\nsub-repos, seems not so easily realisable with git?\n\nA major restriction of git seems that the url's of each sub-repo need to\nbe unique, since they are in the global file .gitmodules? This seems strange\nto me: If every submodule had its repo-specific pull-information, then still\nby foreach-git-pull, where each pull has location-specific information, I\ncould achieve something. \n\nHm, is the way how this is supposed to work really to first do \"git submodule init\",\nto get a false path to the sub-repo into config, and then to change that path?\nThen I have that nonsensic information about the url in .gitmodules?\nAnd I can't just push the whole thing to Github (as I would have hoped)?\nThere is also the old problem that config is not under version control.\nSo \"submodule\" would be just about substituting scripts which run through\na bunch of repos and call, e.g., git pull in each (but with a certain commit in mind)?\n\nAnyway, if that's how it is, please just tell me.\n(And perhaps the use-case is somehow convincing to a developer, and\nsomebody might think about adding \"full\" submodules.)\n\nThanks in any case!\n\nOliver\n"},{"id":"157634","messageId":"201012082225.oB8MP939010091@no.baka.org","threadId":"25999","inReplyTo":"20101208205846.GW29789@cs-wsok.swansea.ac.uk","subject":"Re: how to have real (existing) submodules?","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2010-12-08T22:25:09Z","receivedAt":"2010-12-08T22:25:09Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message <20101208205846.GW29789@cs-wsok.swansea.ac.uk>, Oliver Kullmann writ\nes:\n\n    I thought that \"git submodule\" would solve the problem, but now I\n    realised that these submodules are not \"real\", but they only\n    contain a bit of meta-data (this should really be said directly in\n    the documentation).\n\n    So my hope, that I can have one super-repo, where I say, e.g.,\n    \"git submodule foreach pull\", get the full super-repo, copy it on\n    a memory stick, and then by pulling from that copy I get\n    everything into another super-repo, from which I distribute the\n    sub-repos, seems not so easily realisable with git?\n\ngitslave may work for you better than git-submodules in this specific\nuse case.  http://gitslave.sf.net\n\nIn your example, you would create an organizational super-project git\nmodule which is primarily a container for the .gitslave file which\ntells the system how to access the various git repos and their on-disk\npath names.\n\nGiven your diverse repo locations, it sounds like you will not be\nusing the feature which allows the pathnames of the slave repos to be\nrelative based on the URL to the super-repo (though you could have a\nmixture of relative and absolute URLs if that would help your\nfunctionality).\n\nYou would then run `gits pull` to issue a `git pull` against every\nslave repo, and likewise `gits push` or `gits push home` or whatever.\n(remotes would best work if your gitslave system has relative URLs).\nWhile the super-project cannot be bare, the slave-repos could be bare\nif that would help your data transfer functionality.\n\nIf certain slave repos would not be accessible in all locations, there\nare options to bypass the errors you will get attempting to contact\nthe unreachable repos.\n\nIf you have any questions, please let me know (here, private email, or\non #git).\n\n\t\t\t\t\t-Seth Robertson\n"}]}