Quoting Jakub Narebski <jnareb@xxxxxxxxx> > Steven Noonan <steven@xxxxxxxxxxxxxx> 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html