{"thread":{"id":"9538","subject":"git submodule init and redundant data in .gitmodules/.git/config","startedAt":"2007-08-15T16:20:05Z","lastAt":"2007-08-17T07:14:45Z","messageCount":7,"participants":["martin f krafft","Sven Verdoolaege","Josef Weidendorfer","Lars Hjemli"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50789","messageId":"20070815162005.GA18463@piper.oerlikon.madduck.net","threadId":"9538","inReplyTo":null,"subject":"git submodule init and redundant data in .gitmodules/.git/config","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-15T16:20:05Z","receivedAt":"2007-08-15T16:20:05Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Hi,\n\nI am starting to learn submodules and hit the first state of\nconfusion when I encountered git-submodule init:\n\nAfter git-submodule add, I find in my repository a .gitmodules file\nas well as the newly-cloned submodule. I can call git-submodule\nstatus on it to get the HEAD hash. The .gitmodules file has a stanza\nfor each submodule, linking remote url to local path, e.g.:\n\n  [submodule \"foo\"]\n    path = foo\n    url = ../foo.git\n\nThe manpage then talks about git-submodule init:\n\n    init\n      Initialize the submodules, i.e. register in .git/config each\n      submodule name and url found in .gitmodules. The key used in\n      .git/config is submodule.$name.url. This command does not\n      alter existing information in .git/config.\n\nWhen I run git-submodule init, the following stanza gets added to\n.git/config:\n\n  [submodule \"foo\"]\n    url = ../foo.git\n\nUnless I call init, I cannot use git-submodule update.\n\nBut looking at the two stanzas, it strikes me that the remote url of\nthe submodule is duplicated and detached, creating redundant data\nwhich may become desynchronised.\n\nWhy is this?\n\nWhat is the reason for git-submodule init and moving the data to\n.git/config?\n\nThanks,\n\n-- \nmartin;              (greetings from the heart of the sun.)\n  \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"it is only the modern that ever becomes old-fashioned.\" \n                                                        -- oscar wilde\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"50793","messageId":"20070815163822.GC1070MdfPADPa@greensroom.kotnet.org","threadId":"9538","inReplyTo":"20070815162005.GA18463@piper.oerlikon.madduck.net","subject":"Re: git submodule init and redundant data in .gitmodules/.git/config","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-08-15T16:38:22Z","receivedAt":"2007-08-15T16:38:22Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Wed, Aug 15, 2007 at 06:20:05PM +0200, martin f krafft wrote:\n> But looking at the two stanzas, it strikes me that the remote url of\n> the submodule is duplicated and detached, creating redundant data\n> which may become desynchronised.\n> \n> Why is this?\n> \n> What is the reason for git-submodule init and moving the data to\n> .git/config?\n\nThe (most appropriate) URL from which to get updates of a submodule\nmay be different for different people and therefore has to be stored\nin .git/config.  It was then decided that the default value\nfor this URL should be stored in .gitmodules.  git submodule init\nsimply initializes the URL using this default value.  You are free\nto not call git submodule init and set a (more) appropriate URL manually.\n\nskimo\n"},{"id":"50832","messageId":"20070815222907.GA7395@piper.oerlikon.madduck.net","threadId":"9538","inReplyTo":"20070815163822.GC1070MdfPADPa@greensroom.kotnet.org","subject":"using .gitmodule as default (was: git submodule init and redundant data in .gitmodules/.git/config)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-15T22:29:07Z","receivedAt":"2007-08-15T22:29:07Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Sven Verdoolaege <skimo@kotnet.org> [2007.08.15.1838 +0200]:\n> The (most appropriate) URL from which to get updates of a submodule\n> may be different for different people and therefore has to be stored\n> in .git/config.  It was then decided that the default value\n> for this URL should be stored in .gitmodules.  git submodule init\n> simply initializes the URL using this default value.  You are free\n> to not call git submodule init and set a (more) appropriate URL manually.\n\nAh. I shall prepare a patch against the manpage to make this more\nclear then. Thanks for your explanation.\n\nI have one open question though: why require init? It makes perfect\nsense to allow for a local override, but unless I need to override\nit, git-submodule update should really just keep using the default,\nwhich it does not as far as I can tell from my tests:\n\npiper:/tmp/cdt.tfd29893/co/a> git submodule update\npiper:/tmp/cdt.tfd29893/co/a> git-submodule init\nSubmodule 'b' (/tmp/cdt.tfd29893/repos/b.git) registered for path 'b'\npiper:/tmp/cdt.tfd29893/co/a> git submodule update\nInitialized empty Git repository in /tmp/cdt.tfd29893/co/a/b/.git/\n0 blocks\nSubmodule path 'b': checked out '0c1403bc9e13480e70745b70f79ffb00deb25a8d'\n\nIs there a reason for this or should I try to create a patch, which\nwould make git-submodule consult .gitmodules in addition to\nconfig.submodules for all modules not found in config.submodules.\n\nNow if I may go a step further, I'll claim that init is a misnomer,\nreally. Instead, I would suggest to rename it. Here are some\nthoughts:\n\n  - config\n    there is already git-config, and just like git-svn reuses e.g.\n    rebase, this would keep the taxonomy compact\n  - cpconf\n    it does copy the configuration, after all\n  - override\n    not sure, since it doesn't actually override anything, but sets\n    it all up for the user to be able to override the config\n  - instconf\n    install or instantiate the configuration\n  - localise\n    overloaded word, but it'd be localising configuration in some\n    ways\n  - localconf\n    hinting at making the configuration local\n\nComments welcome,\n\n-- \nmartin;              (greetings from the heart of the sun.)\n  \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nman muss noch chaos in sich haben\num einen tanzenden stern zu gebähren.\n                                                -- friedrich nietzsche\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"50886","messageId":"200708161553.10991.Josef.Weidendorfer@gmx.de","threadId":"9538","inReplyTo":"20070815222907.GA7395@piper.oerlikon.madduck.net","subject":"Re: using .gitmodule as default (was: git submodule init and redundant data in .gitmodules/.git/config)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-08-16T13:53:10Z","receivedAt":"2007-08-16T13:53:10Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 16 August 2007, martin f krafft wrote:\n> also sprach Sven Verdoolaege <skimo@kotnet.org> [2007.08.15.1838 +0200]:\n> > The (most appropriate) URL from which to get updates of a submodule\n> > may be different for different people and therefore has to be stored\n> > in .git/config.  It was then decided that the default value\n> > for this URL should be stored in .gitmodules.  git submodule init\n> > simply initializes the URL using this default value.  You are free\n> > to not call git submodule init and set a (more) appropriate URL manually.\n> \n> Ah. I shall prepare a patch against the manpage to make this more\n> clear then. Thanks for your explanation.\n> \n> I have one open question though: why require init? It makes perfect\n> sense to allow for a local override, but unless I need to override\n> it, git-submodule update should really just keep using the default,\n\nThe information in .gitmodules is only a default value for the URL,\nand not to be actually used. The URL in the config has to exist and\nwill be used for updating. So the config value is not about overriding\nanything, but is required information.\n\nThe URL should not depend on the current revision you have checked out\nat the moment; otherwise, if the default URL in .gitmodules changed at\nsome point in the history, and you check out some earlier commit in the\nsuperproject, the update of the submodule would not work: the\nsubmodule project still resides on the new URL, regardless of the old\ninformation in .gitmodules at the time of the old commit.\n\nJosef\n"},{"id":"50887","messageId":"20070816142133.GA26013@piper.oerlikon.madduck.net","threadId":"9538","inReplyTo":"200708161553.10991.Josef.Weidendorfer@gmx.de","subject":"Re: using .gitmodule as default (was: git submodule init and redundant data in .gitmodules/.git/config)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-16T14:21:33Z","receivedAt":"2007-08-16T14:21:33Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Josef Weidendorfer <Josef.Weidendorfer@gmx.de> [2007.08.16.1553 +0200]:\n> The information in .gitmodules is only a default value for the\n> URL, and not to be actually used. The URL in the config has to\n> exist and will be used for updating. So the config value is not\n> about overriding anything, but is required information.\n\nIt's not required for git-submodule status.\n\n> The URL should not depend on the current revision you have checked\n> out at the moment; otherwise, if the default URL in .gitmodules\n> changed at some point in the history, and you check out some\n> earlier commit in the superproject, the update of the submodule\n> would not work: the submodule project still resides on the new\n> URL, regardless of the old information in .gitmodules at the time\n> of the old commit.\n\nFair point. Thanks,\n\n-- \nmartin;              (greetings from the heart of the sun.)\n  \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"heuristic is computer science jargon for 'doesn't actually work.'\"\n                                                     -- charlie reiman\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"50897","messageId":"200708161839.52749.Josef.Weidendorfer@gmx.de","threadId":"9538","inReplyTo":"20070816142133.GA26013@piper.oerlikon.madduck.net","subject":"Re: using .gitmodule as default (was: git submodule init and redundant data in .gitmodules/.git/config)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-08-16T16:39:52Z","receivedAt":"2007-08-16T16:39:52Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 16 August 2007, martin f krafft wrote:\n> also sprach Josef Weidendorfer <Josef.Weidendorfer@gmx.de> [2007.08.16.1553 +0200]:\n> > The information in .gitmodules is only a default value for the\n> > URL, and not to be actually used. The URL in the config has to\n> > exist and will be used for updating. So the config value is not\n> > about overriding anything, but is required information.\n> \n> It's not required for git-submodule status.\n\nThis can show uninitialized submodules, so that's fine.\n\nAs the URL in .gitmodules is only an initial default, it probably\ncould be optional: if you work on a supermodule with a submodule of your own,\nit is easily possible that you have no idea about what a reasonable default\nof a submodule URL should be at the time you do the first supermodule\ncommit. It makes no sense to have to provide a bogus URL there.\n\nJosef\n"},{"id":"50918","messageId":"8c5c35580708170014i5af2da62w1dbcbad71430e26@mail.gmail.com","threadId":"9538","inReplyTo":"20070815222907.GA7395@piper.oerlikon.madduck.net","subject":"Re: using .gitmodule as default (was: git submodule init and redundant data in .gitmodules/.git/config)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-08-17T07:14:45Z","receivedAt":"2007-08-17T07:14:45Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 8/16/07, martin f krafft <madduck@madduck.net> wrote:\n> I have one open question though: why require init?\n\nThe purpose of 'init' is to inform git-submodule about which\nsubmodules you want to checkout. E.g. for a project with submodules in\ndirectories 'a', 'b' and 'c', you could do\n\n$ git submodule init b c\n$ git submodule update\n\nThis would only fetch/checkout the submodules in direcotories 'b' and\n'c', while 'git submodule status' would still inform you that there is\nactually three submodules available.\n\nNote: If you wanted to initialize all three submodules at once, you\ncould simply do\n\n$ git submodule init\n\n--\nlarsh\n"}]}