{"thread":{"id":"24902","subject":"How to deal with removal/addition of submodules?","startedAt":"2010-08-29T19:38:59Z","lastAt":"2010-08-29T19:38:59Z","messageCount":1,"participants":["Geert Bosch"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"149227","messageId":"5AC1B4DE-62F7-4439-9F2C-72DFC32CEEC1@gnat.com","threadId":"24902","inReplyTo":null,"subject":"How to deal with removal/addition of submodules?","fromName":"Geert Bosch","fromEmail":"bosch@gnat.com","sentAt":"2010-08-29T19:38:59Z","receivedAt":"2010-08-29T19:38:59Z","isPatch":false,"sender":{"key":"bosch@gnat.com","avatar":null},"body":"I'm making an integration project that includes submodules for various\ncomponents and each day makes a commit in the super-project with all\ndesired versions of the components. Because many components come from\nSubversion repositories, I typically import them directly using git \nsvn clone, and then add the submodule using a relative path, such as\ngit submodule add ./some_module.\n\nThe idea is that at any super-project checkout will automatically fetch\nall the correct versions of the components. This seems the ideal use of\nsubmodules. For the most part, this works correctly.\n\nHowever, when creating new submodules, moving submodules around, or\ndeleting submodules, there are problems checking out old versions\nof the project. Basically, when I delete a submodule, git seems to force\nme to remove the entire subdirectory including .git files, which essentially\ngets rid of all its history too. If I would leave the .git files around,\nI wouldn't be able to treat the subdirectory as a regular subdirectory.\n\nProbably I could work around the issue by having separate independent\ngit repositories for each component, so there would be no conflict\nbetween working tree and submodule repository. However, this makes it\nmuch more cumbersome and script-intensive to do automatic nightly updates \nof all component repositories and generally results in an extra level of\nindirection.\n\nIf submodules would just be able to share the master .git directory\nfor their storage, it would seem that most of these problems would\ndisappear. It would still be possible to selectively initialize and\nclone submodules; resulting packs would just share the same .git \ndirectory. They might even be in their own subdirectories of .git,\nthey just need to be found for resolving submodule references.\n\nWith this improved organization it would be trivial to check out\nany old version of the super project, because the commits referenced\nby these versions would be easy to find.\n\nIt seems that currently git itself, apart from its configuration files,\nreally adheres to the \"content is king\" credo, but for submodules we\nare thrown back to making path names special. We have persistent identities\nfor submodules and they cause problems.\n\nMy question: how do I manage submodules without falling in these traps?\n\n  -Geert\n\nPS. Below is a script that shows a problematic chain of events to replace\n    a submodule by a regular subdirectory.\n\ngit init super\ncd super\ngit remote add origin $(pwd)\ngit init sub\ncd sub\necho submodule>txt\ngit add txt\ngit commit -m \"Initial subproject revision\"\ncd ..\ngit submodule add ./sub\ngit commit -m \"Initial super project commit\"\n# The following line is problematic, but what to do instead?\nrm -rf sub\ngit rm sub\nmkdir sub\necho subdirectory>sub/txt\ncd sub\ngit add txt\ngit commit -m \"Sub is now a subdirectory\" txt\ncd ..\n# Repository all done now, let's go back to last revision\ngit checkout HEAD~1\ngit submodule update\ncd ..\n"}]}