On 2007-07-15 06:47, Alex Riesen wrote: > Sven Verdoolaege, Sun, Jul 15, 2007 10:39:59 +0200: >> On Fri, Jul 13, 2007 at 11:46:30PM +0200, VMiklos wrote: >>> i mean, first i thought that after configuring a submodule under libfoo, >>> then a git pull will update libfoo's repo under libfoo, too. or >>> something like that. >> Unless I've missed something, it doesn't. >> Some of use would like git to do just that (at least Alex Riesen, >> Martin Waitz and myself have sent in patches to that effect), >> but we haven't been able to convince Junio yet. > > Count me out. Junio convinced me instead and having tried the > subprojects I find it really convenient: I can choose when and what > should be updated and I can see what _can_ be updated, iff I decide > to. Subprojects defined in such a loosely way are more flexible then > having git-pull fetch subprojects by default. Sometimes I even want be > _sure_ the subprojects are completely untouched (I have some critical > parts in them). All of the above also applies to normal files, not just submodules. So by this logic, maybe "git pull" and "git checkout" should by default update just the index, and require a manual "git file update" to update the files in the working tree? Leaving the working tree (including submodules) in an inconsistent state right after a pull or checkout is a very strange thing to do. It means, for example, that even simple switching between branches doesn't work in a superproject. Consider this example (tested on next aac97aacbccd): -------------------------------------------------- Create the subproject repo: $ mkdir sub-to-be $ cd sub-to-be $ git init $ echo AAA > foo $ git add foo $ git commit -m sub $ cd .. Create the superproject repo and clone subproject into it: $ mkdir super $ cd super $ git init $ git submodule add ../sub-to-be sub $ git commit -m super Update the submodule: $ cd sub $ echo BBB > foo $ git add foo $ git commit -m sub $ cd .. Update the supermodule: $ git add sub $ git commit -m super Try to switch between versions, and fail miserably: $ git checkout -b old HEAD^ M sub Switched to a new branch "old" $ git checkout master fatal: Entry 'sub' not uptodate. Cannot merge. -------------------------------------------------- BTW, is there any easy way to create a submodule directly inside the supermodule's working tree, instead of cloning it as in the above example? Eran - 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