{"thread":{"id":"22784","subject":"Submodules implementation","startedAt":"2010-02-23T23:50:44Z","lastAt":"2010-02-24T00:40:57Z","messageCount":4,"participants":["Christoph Bartoschek","Avery Pennarun","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"135503","messageId":"k76e57-g67.ln1@burns.bruehl.pontohonk.de","threadId":"22784","inReplyTo":null,"subject":"Submodules implementation","fromName":"Christoph Bartoschek","fromEmail":"bartoschek@gmx.de","sentAt":"2010-02-23T23:50:44Z","receivedAt":"2010-02-23T23:50:44Z","isPatch":false,"sender":{"key":"bartoschek@gmx.de","avatar":null},"body":"Hi,\n\nwhat is the main reason that submodules are their own repositories linked \ninto the enclosing one and not just additional pointers in the main \nrepository?\n\nMy impression is that submodules as pointers to existing tree objects would \nmake a design more easier to understand and more user friendly. \nEspecially I see no need for most of the submodule commands. Maybe \"git \nsubmodule add\" but the other commands are already covered by existing ones.\n\nOr is there a tool that uses such additional pointers for submodule \nmanagement?\n\nThanks\nChristoph\n"},{"id":"135505","messageId":"32541b131002231559r49fc31e0i4ce46869d27190c8@mail.gmail.com","threadId":"22784","inReplyTo":"k76e57-g67.ln1@burns.bruehl.pontohonk.de","subject":"Re: Submodules implementation","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-23T23:59:49Z","receivedAt":"2010-02-23T23:59:49Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"2010/2/23 Christoph Bartoschek :\n> what is the main reason that submodules are their own repositories linked\n> into the enclosing one and not just additional pointers in the main\n> repository?\n>\n> My impression is that submodules as pointers to existing tree objects would\n> make a design more easier to understand and more user friendly.\n\nThe data format itself implements submodules as simply pointers to\ncommits (not trees) located at a particular point in the supermodule.\nThis is very elegant and simple.\n\n> Especially I see no need for most of the submodule commands. Maybe \"git\n> submodule add\" but the other commands are already covered by existing ones.\n>\n> Or is there a tool that uses such additional pointers for submodule\n> management?\n\nThe implementation of submodule tools, particularly 'git submodule',\nis the reason that these submodule pointers are implemented as\nseparate repositories. I think the reasons are that a) it seemed\nexpedient at the time, and b) it's one valid way (although not the\nonly way) of thinking about what it means to have one repo point at a\ncommit.\n\nBy comparison, my git-subtree tool\n(http://github.com/apenwarr/git-subtree) is the opposite: its data\nstorage format isn't very elegant (it just has a tree stored inside\nanother tree, as if there were no submodule at all) but its\nimplementation makes it easier for end users (since they don't have to\ndeal with separate repositories).\n\nThe ideal tool would be elegant *and* easy to use, but it doesn't exist.\n\nHave fun,\n\nAvery\n"},{"id":"135507","messageId":"201002240115.53771.bartoschek@gmx.de","threadId":"22784","inReplyTo":"32541b131002231559r49fc31e0i4ce46869d27190c8@mail.gmail.com","subject":"Re: Submodules implementation","fromName":"Christoph Bartoschek","fromEmail":"bartoschek@gmx.de","sentAt":"2010-02-24T00:15:53Z","receivedAt":"2010-02-24T00:15:53Z","isPatch":false,"sender":{"key":"bartoschek@gmx.de","avatar":null},"body":"Am Mittwoch 24 Februar 2010 schrieb Avery Pennarun:\n\n> The data format itself implements submodules as simply pointers to\n> commits (not trees) located at a particular point in the supermodule.\n> This is very elegant and simple.\n\nI see that in the submodule there is a .git directory with its own objects. \nThis does not look like as if the submodule objects are part of the \nsuperproject.\n\n> By comparison, my git-subtree tool\n> (http://github.com/apenwarr/git-subtree) is the opposite: its data\n> storage format isn't very elegant (it just has a tree stored inside\n> another tree, as if there were no submodule at all) but its\n> implementation makes it easier for end users (since they don't have to\n> deal with separate repositories).\n\nThis is exaclty how I would expect it. The tree of the submodule has its root \nsomewhere in the tree of the superproject. Then there are commits for the \nsuperproject that point to the root of the whole tree and commits for the \nsubmodules that point to nodes in the tree.\nA combined tree looks much more elegant for me.\n\nI'll take a look at your tool.\n\nChristop\n"},{"id":"135510","messageId":"7vvddnwjmu.fsf@alter.siamese.dyndns.org","threadId":"22784","inReplyTo":"201002240115.53771.bartoschek@gmx.de","subject":"Re: Submodules implementation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-24T00:40:57Z","receivedAt":"2010-02-24T00:40:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Bartoschek writes:\n\n> I see that in the submodule there is a .git directory with its own objects. \n> This does not look like as if the submodule objects are part of the \n> superproject.\n\nBecause they largely aren't. submodules are freestanding projects on\ntheir own right.\n\nOne of the primary design decisions was to support the use of a\nsuperproject without having to clone/checkout all the submodules.\n\nYou may want to check earlier design discussion thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/31941/focus=32944\n\nIt is a huge thread and some of the messages there might be nothing more\nthan uninformed and unworkable handwaving, except for the ones from Linus\nand some others.\n"}]}