On 13/10/10 13:06, Jens Lehmann wrote: > > For *your* use case it might not be correct, but for others it may very > well be. > > We need to get more user stories like that to get an overview about what > config options are useful and what might be reasonable defaults for them. > And then we can decide what set of options and defaults to choose. We'll if you want it here's an example of how we use submodules at $dayjob. Most developers initially clone the project repo and run git submodule update --init (or git submodule init && git submodule update if their git version is too old). This could be replaced by git clone --recursive, or just git clone if we there was a config for enabling recursive cloning by default. A few newbies have been confused by the fact that they run git clone but don't actually end up with any code (in our case the superprojects are just containers with no actual code themselves). We have a continuous integration machine that does a git pull on all submodules, a few automated tests and updates the superproject if the tests pass. This would make use of git fetch/pull --recursive to grab all the latest changes. After the initial clone developers run git pull on the project. for modules they aren't working on they run git submodule update <module>. For modules they are working on they to rebase their working branch to the SHA1 recorded in the superproject. I think this kind of thing has already been discussed on the list, not sure that I've seen a solution that would work for us. For now all of this is is wrapped in a script for the developers. Developers would probably want the fetch-if-super-gitlink-has-changed behaviour. We also need to handle rebasing a submodule's checkedout branch (if present) against the recorded submodule SHA1. This could remain "our problem" as long as the worktree of these branches does not get updated we can simply use the existing rebase logic we have today. Hope that is a useful use-case. -- - Chris -- 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