{"thread":{"id":"8256","subject":"RFC: submodule terminology","startedAt":"2007-05-20T21:44:17Z","lastAt":"2007-05-21T06:52:34Z","messageCount":10,"participants":["Martin Waitz","Johan Herland","Junio C Hamano","Eric Lesh","Raimund Bauer","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42803","messageId":"20070520214417.GM5412@admingilde.org","threadId":"8256","inReplyTo":null,"subject":"RFC: submodule terminology","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-05-20T21:44:17Z","receivedAt":"2007-05-20T21:44:17Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nI think we should agree to one name for what currently is named\nsubmodule / subproject / dirlink / gitlink.\n\nOr use one name for the low-level plumbing (have a tree entry\nwhich points to another commit): dirlink or gitlink and another\none for the high-level UI think: submodule or subproject.\nBut then we should use those names consequently.\n\nOppinions?\n\n-- \nMartin Waitz\n"},{"id":"42808","messageId":"200705210006.47266.johan@herland.net","threadId":"8256","inReplyTo":"20070520214417.GM5412@admingilde.org","subject":"Re: RFC: submodule terminology","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-20T22:06:47Z","receivedAt":"2007-05-20T22:06:47Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 20 May 2007, Martin Waitz wrote:\n> hoi :)\n> \n> I think we should agree to one name for what currently is named\n> submodule / subproject / dirlink / gitlink.\n> \n> Or use one name for the low-level plumbing (have a tree entry\n> which points to another commit): dirlink or gitlink and another\n> one for the high-level UI think: submodule or subproject.\n> But then we should use those names consequently.\n> \n> Oppinions?\n\n\nFor the high-level concept, \"subproject\" seems to me the best \nalternative. I think it is much better than \"submodule\" at \ndescribing that the subproject is a stand-alone project/repo in\nitself.\n\nAs for the low-level concept, I personally prefer \"gitlink\", but \nI don't have any strong feelings. The fact that \"gitlink\" seems \nto already be used in the code (as in resolve_gitlink_ref() etc.), \ncoupled with \"dirlink\" being somewhat ambiguous (i.e. may also be \ninterpreted as \"(sym)link to directory\") makes the case for me.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"42820","messageId":"7v3b1rje45.fsf@assigned-by-dhcp.cox.net","threadId":"8256","inReplyTo":"200705210006.47266.johan@herland.net","subject":"Re: RFC: submodule terminology","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-20T22:59:22Z","receivedAt":"2007-05-20T22:59:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> On Sunday 20 May 2007, Martin Waitz wrote:\n>> hoi :)\n>> \n>> I think we should agree to one name for what currently is named\n>> submodule / subproject / dirlink / gitlink.\n>> \n>> Or use one name for the low-level plumbing (have a tree entry\n>> which points to another commit): dirlink or gitlink and another\n>> one for the high-level UI think: submodule or subproject.\n>> But then we should use those names consequently.\n>> \n>> Oppinions?\n>\n> For the high-level concept, \"subproject\" seems to me the best \n> alternative. I think it is much better than \"submodule\" at \n> describing that the subproject is a stand-alone project/repo in\n> itself.\n\nI was wondering if we can get away by just calling them\n\"projects\", \"projects containd in the superproject\", etc., as I\ntend to agree with Linus, who used the term \"superproject\nsupport\" in his talk, that this is not really about creating\n\"subproject\" which are somehow different from ordinary projects,\nbut more about supporting superprojects that can contain/point\nat other projects, which we did not have before 1.5.2 happened.\n\n> As for the low-level concept, I personally prefer \"gitlink\", but \n> I don't have any strong feelings.\n\n+1\n"},{"id":"42823","messageId":"20070520230352.GQ5412@admingilde.org","threadId":"8256","inReplyTo":"200705210006.47266.johan@herland.net","subject":"Re: RFC: submodule terminology","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-05-20T23:03:54Z","receivedAt":"2007-05-20T23:03:54Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, May 21, 2007 at 12:06:47AM +0200, Johan Herland wrote:\n> For the high-level concept, \"subproject\" seems to me the best \n> alternative. I think it is much better than \"submodule\" at \n> describing that the subproject is a stand-alone project/repo in\n> itself.\n\nit may be developed independently but for the sake of the more important\nbigger (\"the top level project\") it really is only one small part.\nThat and the fact that \"module\" is already an established term\nin software makes me prefer \"submodule\".\nFor me the project is always the top-level one: the project you\ncurrently work for.\n\n> As for the low-level concept, I personally prefer \"gitlink\", but \n> I don't have any strong feelings. The fact that \"gitlink\" seems \n> to already be used in the code (as in resolve_gitlink_ref() etc.), \n> coupled with \"dirlink\" being somewhat ambiguous (i.e. may also be \n> interpreted as \"(sym)link to directory\") makes the case for me.\n\nThe only problem I have with gitlink is that there already was\na lot of discussion about some entirely different \"gitlink\", so\nchoosing a different name is not that bad.\nAside from that I prefer gitlink, too.\n\n-- \nMartin Waitz\n"},{"id":"42824","messageId":"200705210110.01223.johan@herland.net","threadId":"8256","inReplyTo":"7v3b1rje45.fsf@assigned-by-dhcp.cox.net","subject":"Re: RFC: submodule terminology","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-20T23:10:01Z","receivedAt":"2007-05-20T23:10:01Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 21 May 2007, Junio C Hamano wrote:\n> Johan Herland writes:\n> \n> > On Sunday 20 May 2007, Martin Waitz wrote:\n> >> hoi :)\n> >> \n> >> I think we should agree to one name for what currently is named\n> >> submodule / subproject / dirlink / gitlink.\n> >> \n> >> Or use one name for the low-level plumbing (have a tree entry\n> >> which points to another commit): dirlink or gitlink and another\n> >> one for the high-level UI think: submodule or subproject.\n> >> But then we should use those names consequently.\n> >> \n> >> Oppinions?\n> >\n> > For the high-level concept, \"subproject\" seems to me the best \n> > alternative. I think it is much better than \"submodule\" at \n> > describing that the subproject is a stand-alone project/repo in\n> > itself.\n> \n> I was wondering if we can get away by just calling them\n> \"projects\", \"projects containd in the superproject\", etc., as I\n> tend to agree with Linus, who used the term \"superproject\n> support\" in his talk, that this is not really about creating\n> \"subproject\" which are somehow different from ordinary projects,\n> but more about supporting superprojects that can contain/point\n> at other projects, which we did not have before 1.5.2 happened.\n\nI agree that superproject is probably the best term of all. However, \nI think it's a good idea to be explicit so as to avoid unnecessary \nconfusion. My vote therefore goes to \"superproject/subproject\" \nrather than \"superproject/project\".\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"42827","messageId":"200705210116.25079.johan@herland.net","threadId":"8256","inReplyTo":"20070520230352.GQ5412@admingilde.org","subject":"Re: RFC: submodule terminology","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-20T23:16:24Z","receivedAt":"2007-05-20T23:16:24Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 21 May 2007, Martin Waitz wrote:\n> hoi :)\n> \n> On Mon, May 21, 2007 at 12:06:47AM +0200, Johan Herland wrote:\n> > For the high-level concept, \"subproject\" seems to me the best \n> > alternative. I think it is much better than \"submodule\" at \n> > describing that the subproject is a stand-alone project/repo in\n> > itself.\n> \n> it may be developed independently but for the sake of the more important\n> bigger (\"the top level project\") it really is only one small part.\n> That and the fact that \"module\" is already an established term\n> in software makes me prefer \"submodule\".\n> For me the project is always the top-level one: the project you\n> currently work for.\n\n\"The project you currently work for\" depends on your POV. But I agree\nthat using the term \"project\" alone might be confusing. That's why I'd\nrather talk about \"superproject\" and \"subproject\". That way, there's\nno ambiguity at all.\n\n> > As for the low-level concept, I personally prefer \"gitlink\", but \n> > I don't have any strong feelings. The fact that \"gitlink\" seems \n> > to already be used in the code (as in resolve_gitlink_ref() etc.), \n> > coupled with \"dirlink\" being somewhat ambiguous (i.e. may also be \n> > interpreted as \"(sym)link to directory\") makes the case for me.\n> \n> The only problem I have with gitlink is that there already was\n> a lot of discussion about some entirely different \"gitlink\", so\n> choosing a different name is not that bad.\n> Aside from that I prefer gitlink, too.\n\nThe term \"gitlink\" is ambiguous/confusing? I didn't know. What's the \nother meaning of gitlink?\n\n(Unless you're talking about gitlink as in \"gitlink:git[7]\" which \nappears all over our asciidoc documentation, but I don't think that \ncounts...)\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"42829","messageId":"20070520233913.GT5412@admingilde.org","threadId":"8256","inReplyTo":"200705210116.25079.johan@herland.net","subject":"Re: RFC: submodule terminology","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-05-20T23:39:14Z","receivedAt":"2007-05-20T23:39:14Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, May 21, 2007 at 01:16:24AM +0200, Johan Herland wrote:\n> The term \"gitlink\" is ambiguous/confusing? I didn't know. What's the \n> other meaning of gitlink?\n\nthere was some talk about lightweight checkouts using some .gitlink\nfile instead of a .git directory.\n\n-- \nMartin Waitz\n"},{"id":"42837","messageId":"1179707569.11098.1.camel@localhost","threadId":"8256","inReplyTo":"20070520233913.GT5412@admingilde.org","subject":"Re: RFC: submodule terminology","fromName":"Eric Lesh","fromEmail":"eclesh@ucla.edu","sentAt":"2007-05-21T00:32:49Z","receivedAt":"2007-05-21T00:32:49Z","isPatch":false,"sender":{"key":"eclesh@ucla.edu","avatar":null},"body":"On Mon, 2007-05-21 at 01:39 +0200, Martin Waitz wrote:\n> hoi :)\n> \n> On Mon, May 21, 2007 at 01:16:24AM +0200, Johan Herland wrote:\n> > The term \"gitlink\" is ambiguous/confusing? I didn't know. What's the \n> > other meaning of gitlink?\n> \n> there was some talk about lightweight checkouts using some .gitlink\n> file instead of a .git directory.\n> \n\nThis was my project, but if I end up trying to do lightweight checkouts\nI'll avoid a .gitlink file most likely (and go with something\nin .git/config instead). Gitlink is therefore quite safe.\n\n-Eric\n"},{"id":"42848","messageId":"1179729886.6187.15.camel@localhost","threadId":"8256","inReplyTo":"7v3b1rje45.fsf@assigned-by-dhcp.cox.net","subject":"Re: RFC: submodule terminology","fromName":"Raimund Bauer","fromEmail":"ray007@gmx.net","sentAt":"2007-05-21T06:44:46Z","receivedAt":"2007-05-21T06:44:46Z","isPatch":false,"sender":{"key":"ray007@gmx.net","avatar":null},"body":"On Sun, 2007-05-20 at 15:59 -0700, Junio C Hamano wrote:\n> I was wondering if we can get away by just calling them\n> \"projects\", \"projects containd in the superproject\", etc., as I\n> tend to agree with Linus, who used the term \"superproject\n> support\" in his talk, that this is not really about creating\n> \"subproject\" which are somehow different from ordinary projects,\n> but more about supporting superprojects that can contain/point\n> at other projects, which we did not have before 1.5.2 happened.\n\nThe \"super\" or \"sub\" only comes from where in a hierarchy it is used.\nSomewhere in the middle of the hierarchy it would be both?\n\nI'd have said a repository can have many \"modules\" or \"projects\", and\neach of those can have several branches. A module can hold other\nmodules, but from its POV also be part of a super-module (or\nsuperproject), we just have to take care to not build loops.\n\nIs my view of the world correct so far?\n\n-- \nbest regards\n\n Ray\n"},{"id":"42849","messageId":"20070521065234.GM3141@spearce.org","threadId":"8256","inReplyTo":"1179729886.6187.15.camel@localhost","subject":"Re: RFC: submodule terminology","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-21T06:52:34Z","receivedAt":"2007-05-21T06:52:34Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Raimund Bauer wrote:\n> On Sun, 2007-05-20 at 15:59 -0700, Junio C Hamano wrote:\n> > I was wondering if we can get away by just calling them\n> > \"projects\", \"projects containd in the superproject\", etc., as I\n> > tend to agree with Linus, who used the term \"superproject\n> > support\" in his talk, that this is not really about creating\n> > \"subproject\" which are somehow different from ordinary projects,\n> > but more about supporting superprojects that can contain/point\n> > at other projects, which we did not have before 1.5.2 happened.\n> \n> The \"super\" or \"sub\" only comes from where in a hierarchy it is used.\n> Somewhere in the middle of the hierarchy it would be both?\n\nYes. Of course.\n \n> I'd have said a repository can have many \"modules\" or \"projects\", and\n> each of those can have several branches. A module can hold other\n> modules, but from its POV also be part of a super-module (or\n> superproject), we just have to take care to not build loops.\n\nYou cannot build a loop. OK, let me rephrase:\n\nI can build a loop where at one point in time project A uses project\nB as his subproject; then later I can have project B use project\nA as a subproject. That's a loop. But the commits themselves are\nnot in a cycle. There is a specific version of A that requires a\nspecific version of B, and there is a different version of B that\nrequires an entirely different version of A.\n\nThis loop really just means we have to be smart about how we switch\nbetween versions of a project. Just like if B is required in one\nversion of superproject A and not in another; when I switch back\nand forth in A I expect B to appear/disappear. And I expect it\nto work on an airplane, where network access to reclone B is not\navailable (or is too costly). That means we have to \"hide\" B when\nits not needed.\n\nIf you can actually form a loop where version of A requires version\nof B and version of B requires the version of A that requires the\nversion of B... that's a SHA-1 hash collision. If you can make\nthem at will, you probably can make some good money illegally...\n\n> Is my view of the world correct so far?\n\nYes.\n\n-- \nShawn.\n"}]}