On 03/31/2011 07:41 PM, Jens Lehmann wrote: > We are in a similar situation at my dayjob, but we handled the issue in > a different way. We were reluctant to check in generated files into our > repository, so we decided to distribute them via zip files. We have a > beefy build machine which builds and tests master over night and if > everything went ok it zips the whole work tree including .git directory, > build artifacts and submodules into one file. Then each developer just > has to unpack this file, fetch from the git server and he is all set. > We have something a bit similar for cross project dependencies. We just store in project a file with the SHA1 to another one and we have a server which stores all the packages ever generated and a sqliteDB to have the SHA1 <=> package relation. It works but it requires to add DB files, CGI script to update/query the DB... So we limited this only to a few dependencies between otherwise separated projects. For the rest, it's just easier to commit generated small files. > > Me too agrees that being able to reset a whole work tree including all > submodules recursively makes a lot of sense. But I would not be so happy > seeing this functionality being added to the git-submodule.sh script, as > I believe it belongs into "git reset", so you'll just have to do a "git > reset --hard --recurse-submodules" and you are done. > Yes it is probably easier and clearer for everyone to put it into the dedicated command. This way you know it does the same thing it usually does except on all submodules. Thinking about "git submodule reset" I started wondering about what should be done for indexes, checked out files, ignored files and so on, and whatever is chosen it will confuse pretty much everyone. Also a git clean --recurse-submodules would be nice ! > In the branch "git-checkout-recurse-submodules" in my github repo (which > is at https://github.com/jlehmann/git-submod-enhancements) you can see a > preliminary implementation of that (it works and I use it every day at my > job. It has recursion enabled by default at the moment yet still might > overwrite local changes even if it shouldn't, so use with care ;-). > I'll have a look at it. For the moment I use a bash script which recurse in all submodules doing git clean and git checkout all other the place (it also works with old gits that lack all the foreach and --recursive features) >> But I also still think having a --force option to update does too, in the way Jens proposed it (only on submodule that actually needed a checkout), don't you? > > Yes, I still think it makes sense to add the "-f" flag to submodule update. > If Junio agrees with the idea, I'll repost a much simpler version of the path that just add -f for the submodules that needs it. Nicolas Morey-Chaisemartin -- 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