{"thread":{"id":"21267","subject":"git submodules","startedAt":"2009-10-17T17:15:50Z","lastAt":"2009-10-21T19:38:27Z","messageCount":4,"participants":["Steven Noonan","Jakub Narebski","Nanako Shiraishi","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125249","messageId":"f488382f0910171015j1a6d4d9fg690867154334c514@mail.gmail.com","threadId":"21267","inReplyTo":null,"subject":"git submodules","fromName":"Steven Noonan","fromEmail":"steven@uplinklabs.net","sentAt":"2009-10-17T17:15:50Z","receivedAt":"2009-10-17T17:15:50Z","isPatch":false,"sender":{"key":"steven@uplinklabs.net","avatar":"https://gravatar.com/avatar/b0cd397a10638433f76e084531aa0af3bef85f8fdb59b1ebe2ddaf168cd100e9?d=mp&s=160"},"body":"One of the open source projects I work on (CC'd) recently moved to\ngit, but we're having some slight problems, and I believe that it's\nthe fault of git's UI in this case.\n\nWe're using git submodules for the contributing libraries. When I\ncommit changes to those contribs, it correctly shows in the parent\nrepository that those folders have different revisions than what's\ncurrently committed. However, if someone pulls those changes, it\ndoesn't automatically update the contribs to match the committed\nversion. But doing a pull or merge _should_ update the working tree to\nmatch the committed versions. It does with file data, so why not\nupdate the submodules? Especially if the submodule revision matched\nthe committed version -before- the pull. Why are we forced into using\n'git submodule update'?\n\n- Steven\n"},{"id":"125250","messageId":"m3tyxydj8f.fsf@localhost.localdomain","threadId":"21267","inReplyTo":"f488382f0910171015j1a6d4d9fg690867154334c514@mail.gmail.com","subject":"Re: git submodules","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-10-17T17:27:00Z","receivedAt":"2009-10-17T17:27:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Steven Noonan writes:\n\n> We're using git submodules for the contributing libraries. When I\n> commit changes to those contribs, it correctly shows in the parent\n> repository that those folders have different revisions than what's\n> currently committed. However, if someone pulls those changes, it\n> doesn't automatically update the contribs to match the committed\n> version. But doing a pull or merge _should_ update the working tree to\n> match the committed versions. It does with file data, so why not\n> update the submodules? Especially if the submodule revision matched\n> the committed version -before- the pull. Why are we forced into using\n> 'git submodule update'?\n\nBecause you might want not to use most current version of submodule,\nso git-pull shouldn't update submodules by default. And because\ngit-pull didn't learn --recursive option yet.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"125261","messageId":"20091018073039.6117@nanako3.lavabit.com","threadId":"21267","inReplyTo":"m3tyxydj8f.fsf@localhost.localdomain","subject":"Re: git submodules","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-10-17T22:30:39Z","receivedAt":"2009-10-17T22:30:39Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Jakub Narebski \n\n> Steven Noonan writes:\n>\n>> We're using git submodules for the contributing libraries. When I\n>> commit changes to those contribs, it correctly shows in the parent\n>> repository that those folders have different revisions than what's\n>> currently committed. However, if someone pulls those changes, it\n>> doesn't automatically update the contribs to match the committed\n>> version. But doing a pull or merge _should_ update the working tree to\n>> match the committed versions. It does with file data, so why not\n>> update the submodules? Especially if the submodule revision matched\n>> the committed version -before- the pull. Why are we forced into using\n>> 'git submodule update'?\n>\n> Because you might want not to use most current version of submodule,\n> so git-pull shouldn't update submodules by default. And because\n> git-pull didn't learn --recursive option yet.\n\nI don't think your description is correct. Steven is talking about what the command should do by default. If you checked out the current superproject, by default you should get the submodule that matches. If you don't want the most current version, you can checkout an older submodule yourself.\n\nYou may want to follow this discussion:\n\n http://thread.gmane.org/gmane.comp.version-control.git/130155/focus=130330\n\nAfter stating that he isn't against the idea to make it automatic, Junio describes what needs to be done for it to happen and what are the corner cases that needs to be treated with care.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"125634","messageId":"32541b130910211238s6f4a04cawd7f95c4731fe4a3b@mail.gmail.com","threadId":"21267","inReplyTo":"f488382f0910171015j1a6d4d9fg690867154334c514@mail.gmail.com","subject":"Re: git submodules","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-10-21T19:38:27Z","receivedAt":"2009-10-21T19:38:27Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Sat, Oct 17, 2009 at 1:15 PM, Steven Noonan wrote:\n> We're using git submodules for the contributing libraries. When I\n> commit changes to those contribs, it correctly shows in the parent\n> repository that those folders have different revisions than what's\n> currently committed. However, if someone pulls those changes, it\n> doesn't automatically update the contribs to match the committed\n> version. But doing a pull or merge _should_ update the working tree to\n> match the committed versions. It does with file data, so why not\n> update the submodules? Especially if the submodule revision matched\n> the committed version -before- the pull. Why are we forced into using\n> 'git submodule update'?\n\n\ngit-subtree (http://github.com/apenwarr/git-subtree) is an alternative\nto submodules that doesn't have this problem.\n\n\nBut it probably has other problems. :) Works great for my purposes,\nthough, and quite a few people have contacted me to say they're using\nit happily.\n\nHave fun,\n\nAvery\n"}]}