{"thread":{"id":"21309","subject":"[RFC] What to you think about a loose status for submodules?","startedAt":"2009-10-21T16:01:23Z","lastAt":"2010-01-20T19:45:50Z","messageCount":6,"participants":["Heiko Voigt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125609","messageId":"20091021160122.GA2067@book.hvoigt.net","threadId":"21309","inReplyTo":null,"subject":"[RFC] What to you think about a loose status for submodules?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-10-21T16:01:23Z","receivedAt":"2009-10-21T16:01:23Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nfor some time now I have been thinking about submodules which are\nnot checked out by default. So for example if you have a project which\nconsist of the submodules:\n\nproject/core\n /help\n /app\n...\n\nConsider the situation that 'help' is really big because it is a user\nfriendly application ;)\n\nSo you usually do not need the help folder to develop the application\nbut it still is tied to a certain revision.\n\nFor such a workflow I would like to implement what I call 'loose'\nsubmodules. Where a\n\n git clone project.git\n cd project\n git submodule init && git submodule update\n\nwould omit the 'help' folder. But in case I specify it directly like\n\n git submodule init help\n\nit would update to the recorded revision.\n\nOf course the relation would be configurable. E.g.:\n\n git config submodule.\"name\".relation loose\n\nand the opposite as\n\n git config submodule.\"name\".relation tight\n\nInitially the implementation would only deal with the initialization\ncase. As a second step I would like to deal with the situation whether a\nsubmodule should be shown as changed or not. What do you think about such\nan extension?\n\ncheers Heiko\n"},{"id":"125640","messageId":"7vy6n4339k.fsf@alter.siamese.dyndns.org","threadId":"21309","inReplyTo":"20091021160122.GA2067@book.hvoigt.net","subject":"Re: [RFC] What to you think about a loose status for submodules?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T20:23:19Z","receivedAt":"2009-10-21T20:23:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> For such a workflow I would like to implement what I call 'loose'\n> submodules. Where a\n>\n> git clone project.git\n> cd project\n> git submodule init && git submodule update\n>\n> would omit the 'help' folder. But in case I specify it directly like\n\nI thought a blanket \"submodule init/update\" wasn't even a recommended\npractice for this exact reason. We tried to keep the default not to\ngratuitously populate and checkout all submodule repositories, but\nprobably what you are trying to do was made more difficult by mistake\nbecause people who wanted the other behaviour pushed too hard?\n\nDefaulting to \"do not populate and checkout unless explicitly asked\"\nsounds like the right thing to do, and if we broke it, it should be\ncorrected, I think. Shouldn't it be a simple matter of teaching \"--all\"\noption to \"submodule init\" (and \"update\") to let them blindly affect all\nsubmodules, while making the default not to do anything?\n\n> git submodule init help\n>\n> it would update to the recorded revision.\n>\n> Of course the relation would be configurable. E.g.:\n>\n> git config submodule.\"name\".relation loose\n>\n> and the opposite as\n>\n> git config submodule.\"name\".relation tight\n\nI do not think this should be a project-wide configuration that is\nrecorded in .gitmodules; if you are \"help documentation\" participant to\nthe project you would want \"help\" submodule, and other people will want\ndifferent submodules.\n\nIt would probably make more sense to introduce the notion of \"module\ngroups\", similar to the way \"remote update \" can name a group of\nremotes to affect. Then documentation people can say\n\n submodule init doc && submodule update\n\nif .gitmodules file records the mapping from \"doc\" to one or more\nsubmodules (e.g. \"help\" and \"doc\"). If we are going to take this route,\nit would still make sense to teach \"--all\" to \"submodule init\" and perhaps\ndefault to init the \"default\" group if one exists, instead of making the\nparameterless \"init\" a no-op as I suggested earlier.\n\nBut it is quite a long time since I looked at git-submodule.sh so please\ntake the above with a healthy dose of salt.\n"},{"id":"125729","messageId":"20091022194446.GA3944@book.hvoigt.net","threadId":"21309","inReplyTo":"7vy6n4339k.fsf@alter.siamese.dyndns.org","subject":"Re: Re: [RFC] What to you think about a loose status for submodules?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-10-22T19:44:47Z","receivedAt":"2009-10-22T19:44:47Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Wed, Oct 21, 2009 at 01:23:19PM -0700, Junio C Hamano wrote:\n> Heiko Voigt writes:\n> \n> > For such a workflow I would like to implement what I call 'loose'\n> > submodules. Where a\n> >\n> > git clone project.git\n> > cd project\n> > git submodule init && git submodule update\n> >\n> > would omit the 'help' folder. But in case I specify it directly like\n> \n> I thought a blanket \"submodule init/update\" wasn't even a recommended\n> practice for this exact reason. We tried to keep the default not to\n> gratuitously populate and checkout all submodule repositories, but\n> probably what you are trying to do was made more difficult by mistake\n> because people who wanted the other behaviour pushed too hard?\n\nCurrently if a project has submodule its either use all submodules or\nnone. There is nothing in between.\n\n> Defaulting to \"do not populate and checkout unless explicitly asked\"\n> sounds like the right thing to do, and if we broke it, it should be\n> corrected, I think. Shouldn't it be a simple matter of teaching \"--all\"\n> option to \"submodule init\" (and \"update\") to let them blindly affect all\n> submodules, while making the default not to do anything?\n\nNot completely. As said above I want something 'in between' because some\nsmall submodule might be necessary to compile the project. And they are\nsubmodules because they are shared code, so more than one project is\nusing them. And then there are optional submodules like pugins or\ndocumentation which are not needed for compilation.\n\n> > git config submodule.\"name\".relation tight\n> \n> I do not think this should be a project-wide configuration that is\n> recorded in .gitmodules; if you are \"help documentation\" participant to\n> the project you would want \"help\" submodule, and other people will want\n> different submodules.\n> \n> It would probably make more sense to introduce the notion of \"module\n> groups\", similar to the way \"remote update \" can name a group of\n> remotes to affect. Then documentation people can say\n> \n> submodule init doc && submodule update\n\nThat makes sense. If I understand it correctly the group definitions\nwould then be stored in .gitmodules ?\n\nThinking further we could also name the group definition 'view'. In the\nnotion of different kind of views for a project. That way a doc\ndeveloper would get a set of options which make more sense for him\n(thinking about extending this to sparse checkout). But first lets\nconsider submodules.\n\n> if .gitmodules file records the mapping from \"doc\" to one or more\n> submodules (e.g. \"help\" and \"doc\"). If we are going to take this route,\n> it would still make sense to teach \"--all\" to \"submodule init\" and perhaps\n> default to init the \"default\" group if one exists, instead of making the\n> parameterless \"init\" a no-op as I suggested earlier.\n\nI like this idea.\n\n> But it is quite a long time since I looked at git-submodule.sh so please\n> take the above with a healthy dose of salt.\n\nI am not sure what is the best way to create such a group mapping using\nour config files though. I would like to allow multiple groups/views to\nhave the submodules like:\n\n[submodule \"doc\"]\n\tpath = Documentation\n\tviews = doc\n\n[submodule \"help\"]\n\tpath = help\n\tviews = doc\n\n[submodule \"core\"]\n\tpath = core\n\tviews = doc default\n\n[submodule \"app\"]\n\tpath = app\n\tviews = default\n\nWhat do you think?\n\ncheers Heiko\n"},{"id":"125731","messageId":"7vvdi7fbg3.fsf@alter.siamese.dyndns.org","threadId":"21309","inReplyTo":"20091022194446.GA3944@book.hvoigt.net","subject":"Re: [RFC] What to you think about a loose status for submodules?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-22T19:58:04Z","receivedAt":"2009-10-22T19:58:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> I am not sure what is the best way to create such a group mapping using\n> our config files though. I would like to allow multiple groups/views to\n> have the submodules like:\n>\n> [submodule \"doc\"]\n> \tpath = Documentation\n> \tviews = doc\n>\n> [submodule \"help\"]\n> \tpath = help\n> \tviews = doc\n>\n> [submodule \"core\"]\n> \tpath = core\n> \tviews = doc default\n>\n> [submodule \"app\"]\n> \tpath = app\n> \tviews = default\n>\n> What do you think?\n\nThat, or alternatively:\n\n [submodule \"doc\"]\n path = Documentation\n\n [submodule \"help\"]\n path = help\n\n [submodule \"core\"]\n path = core\n\n [submodule \"app\"]\n path = app\n\n [view \"default\"]\n modules = core app\n\n [view \"doc\"]\n modules = core doc help\n\nOr even (mimicking the way how \"git remote\" defines remote groups):\n\n [submodule \"doc\"]\n path = Documentation\n\n [submodule \"help\"]\n path = help\n\n [submodule \"core\"]\n path = core\n\n [submodule \"app\"]\n path = app\n\n [submodule]\n default = core app\n doc = core doc help\n"},{"id":"132204","messageId":"20100120181652.GA10803@book.hvoigt.net","threadId":"21309","inReplyTo":"7vvdi7fbg3.fsf@alter.siamese.dyndns.org","subject":"Re: Re: [RFC] What to you think about a loose status for submodules?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2010-01-20T18:16:58Z","receivedAt":"2010-01-20T18:16:58Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Oct 22, 2009 at 12:58:04PM -0700, Junio C Hamano wrote:\n> Heiko Voigt writes:\n> \n> > I am not sure what is the best way to create such a group mapping using\n> > our config files though. I would like to allow multiple groups/views to\n> > have the submodules like:\n> > What do you think?\n> \n> That, or alternatively:\n> \n> [submodule \"doc\"]\n> path = Documentation\n> \n> [submodule \"help\"]\n> path = help\n> \n> [submodule \"core\"]\n> path = core\n> \n> [submodule \"app\"]\n> path = app\n> \n> [view \"default\"]\n> modules = core app\n> \n> [view \"doc\"]\n> modules = core doc help\n\nEven though there has not been much more work on this item the idea has\nbecome much clearer for me since the last discussion. Now that sparse\ncheckout is in master I would like to generalize this idea a little\nfurther.\n\nHow about adding this to .gitattributes so it can be used for any\nfile/directory? E.g.:\n\n.gitattributes:\n/core view=default, doc\n/app view=default\n/Documentation view=doc\n*.loc view=doc, default\n\nwhich could then be utilized by\n\n git checkout --view=doc\n\nfor example. If no view is given we default to everything.\n\nDoes the current sparse implementation work with submodule entries as\nwell? Then it could be even more straightforward to implement than the\nprevious idea.\n\ncheers Heiko\n"},{"id":"132208","messageId":"7v7hrc36hd.fsf@alter.siamese.dyndns.org","threadId":"21309","inReplyTo":"20100120181652.GA10803@book.hvoigt.net","subject":"Re: [RFC] What to you think about a loose status for submodules?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-20T19:45:50Z","receivedAt":"2010-01-20T19:45:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> Even though there has not been much more work on this item the idea has\n> become much clearer for me since the last discussion. Now that sparse\n> checkout is in master I would like to generalize this idea a little\n> further.\n\nSelective init/update of submodules is a fundamental design element and\nthe presense of \"sparse checkout\" does not affect it.\n\nIn the remainder of your message\n\n> How about ...\n\nyou are talking about a change that would also apply to a project that\ndoes not have submodules at all, and you would want to involve Nguyễn in\nthe discussion.\n\nI have no strong opinion if attributes is the right vehicle to carry this\ninformation, except for this part:\n\n> Does the current sparse implementation work with submodule entries as\n> well? Then it could be even more straightforward to implement than the\n> previous idea.\n\nWhat the project ships as grouping suggestions to cloners is merely a\nsmall part of the information on submodules (others such as URL and name\nare already found in .gitmodules, and .gitmodules are designed to be\nextensible by allowing other \"config\"-ish items in it). Separating only\nthe grouping info into a different file (I don't particularly care if you\nuse .gitattributes or something else; as long as it is not .gitmodules,\nthe argument is the same) is not such a good idea.\n"}]}