# git submodules 4 messages from 2009-10-17 to 2009-10-21. Participants: Steven Noonan, Jakub Narebski, Nanako Shiraishi, Avery Pennarun. Thread: https://gitlist.dev/t/21267 ## Steven Noonan, 2009-10-17 17:15 Subject: git submodules Message-ID: URL: https://gitlist.dev/e/f488382f0910171015j1a6d4d9fg690867154334c514%40mail.gmail.com ``` One of the open source projects I work on (CC'd) recently moved to git, but we're having some slight problems, and I believe that it's the fault of git's UI in this case. We're using git submodules for the contributing libraries. When I commit changes to those contribs, it correctly shows in the parent repository that those folders have different revisions than what's currently committed. However, if someone pulls those changes, it doesn't automatically update the contribs to match the committed version. But doing a pull or merge _should_ update the working tree to match the committed versions. It does with file data, so why not update the submodules? Especially if the submodule revision matched the committed version -before- the pull. Why are we forced into using 'git submodule update'? - Steven ``` ## Jakub Narebski, 2009-10-17 17:27 Subject: Re: git submodules Message-ID: URL: https://gitlist.dev/e/m3tyxydj8f.fsf%40localhost.localdomain In-Reply-To: ``` Steven Noonan writes: > We're using git submodules for the contributing libraries. When I > commit changes to those contribs, it correctly shows in the parent > repository that those folders have different revisions than what's > currently committed. However, if someone pulls those changes, it > doesn't automatically update the contribs to match the committed > version. But doing a pull or merge _should_ update the working tree to > match the committed versions. It does with file data, so why not > update the submodules? Especially if the submodule revision matched > the committed version -before- the pull. Why are we forced into using > 'git submodule update'? Because you might want not to use most current version of submodule, so git-pull shouldn't update submodules by default. And because git-pull didn't learn --recursive option yet. -- Jakub Narebski Poland ShadeHawk on #git ``` ## Nanako Shiraishi, 2009-10-17 22:30 Subject: Re: git submodules Message-ID: <20091018073039.6117@nanako3.lavabit.com> URL: https://gitlist.dev/e/20091018073039.6117%40nanako3.lavabit.com In-Reply-To: ``` Quoting Jakub Narebski > Steven Noonan writes: > >> We're using git submodules for the contributing libraries. When I >> commit changes to those contribs, it correctly shows in the parent >> repository that those folders have different revisions than what's >> currently committed. However, if someone pulls those changes, it >> doesn't automatically update the contribs to match the committed >> version. But doing a pull or merge _should_ update the working tree to >> match the committed versions. It does with file data, so why not >> update the submodules? Especially if the submodule revision matched >> the committed version -before- the pull. Why are we forced into using >> 'git submodule update'? > > Because you might want not to use most current version of submodule, > so git-pull shouldn't update submodules by default. And because > git-pull didn't learn --recursive option yet. I 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. You may want to follow this discussion: http://thread.gmane.org/gmane.comp.version-control.git/130155/focus=130330 After 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. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ``` ## Avery Pennarun, 2009-10-21 19:38 Subject: Re: git submodules Message-ID: <32541b130910211238s6f4a04cawd7f95c4731fe4a3b@mail.gmail.com> URL: https://gitlist.dev/e/32541b130910211238s6f4a04cawd7f95c4731fe4a3b%40mail.gmail.com In-Reply-To: ``` On Sat, Oct 17, 2009 at 1:15 PM, Steven Noonan wrote: > We're using git submodules for the contributing libraries. When I > commit changes to those contribs, it correctly shows in the parent > repository that those folders have different revisions than what's > currently committed. However, if someone pulls those changes, it > doesn't automatically update the contribs to match the committed > version. But doing a pull or merge _should_ update the working tree to > match the committed versions. It does with file data, so why not > update the submodules? Especially if the submodule revision matched > the committed version -before- the pull. Why are we forced into using > 'git submodule update'? git-subtree (http://github.com/apenwarr/git-subtree) is an alternative to submodules that doesn't have this problem. But it probably has other problems. :) Works great for my purposes, though, and quite a few people have contacted me to say they're using it happily. Have fun, Avery ```