Jens Lehmann wrote: > Am 30.11.2011 01:55, schrieb Max Krasnyansky: > I'm working on a patch series to teach Git to optionally update the > submodules work trees on checkout, reset merge and so on, but I'm not > there yet. > >> I'm thinking about adding a config option that would enable automatic >> submodule update but wanted to see if there is some fundamental reason >> why it would not be accepted. Because there is no good way to do so. It would be fine when you just track the submodules "read-only", but if you are actually working on submodules, it is a bad idea to always get a detached HEAD. It is also a bad idea to merge or rebase on the currently checkedout branch. Because if you are working on a maint branch in the submodule and then you checkout a pu branch in the superproject, because you have forgotten that maint branch in the submodule then all the proposed updates go to the maintenance branch -> bad. So auto-update is not easy. But below I describe an idea that might solve these issues and help auto-udpate to work in a sane way. > I think adding something like an "submodule.autoupdate" config makes lots > of sense, but IMO it should affect all work tree updating porcelain > commands, not just merge. I was thinking about submodule integration and had the idea to bind a submodule to the superproject by having special references in the submodule like refs/super/master, refs/super/featureX... So these references are like tracking branches for the refs/heads/* of the superproject. If you have tracking branches, the supermodule can just update the corresponding branch. If this branch is currently checkedout and the work area is clean, then the work area is updated, too. If there is currently a local branch or a diffent super-branch checked out then the working area should be considered "detached" from the superproject and not updated. With this concept you could even switch branches in the superproject and the attached submodules follow - still having no detached HEAD. When you want to do some local work on the submodule you checkout a local branch and merge back into the super branch later. The head of that super branch might have changed by the update procedure meanwhile, but that is fine, then you just have a merge instead of a fast-forward. Another nice feature would be a recursive commit. So all changed index files in the _attached_ submodules would first be committed in their submodules and then the superproject commits too - all with one command. Currently it feels a little bit like CVS - commit one file(submodule), commit the other file(submodule) and then apply a label(commit the superproject) to keep the changes together. If the submodule is not attached the commit in the superproject can still detect changes that have been made to the corresponding tracking branch and pick these up. As a summary: Tracking submodule branches in the superproject instead of only the current HEAD of the submodule gives you more freedom to install sane auto-update procedures. Even though it will raise a lot of detailed questions like "should the refs/super/* be pushed/pulled when syncing the submodule repositories". -- 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