Am 06.12.2011 02:06, schrieb Max Krasnyansky: > On 11/30/2011 12:31 AM, Jens Lehmann wrote: >> 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. > Everything you suggested sounds great. We're on the same page (config option, etc). > How far along are you? Do you have a tree I could pull from to play with things? > I could help with testing, bug fixes and/or implementing parts of it. Let me know. Great to hear that! Please see my GitHub repo for the current state: https://github.com/jlehmann/git-submod-enhancements It has two interesting branches: git-checkout-recurse-submodules: This was my first attempt to tell unpack_trees() to checkout submodules and works quite well. Porcelain checks out submodules by default while plumbing learned the --recurse-submodules option to do that (and git gui and gitk use that option so stuff like "Revert Changes" does work on submodules :-). I use it at work for some time and it works quite well, but doesn't handle new or deleted submodules. And unfortunately the way I added the flag to control submodule checkout doesn't allow to add a per-submodule configuration option. recursive_submodule_checkout: This is where new development happens. I added the basic infrastructure to have global and per-submodule configuration controlling the checkout and ported the unpack_trees() changes from git-checkout-recurse-submodules here. I also added removal and creation of submodules based on the now moved gitdir. This branch has rudimentary tests but still needs quite some work. I expect to have some time around the end of year to move things forward. It'd be cool if you could check the current state, after that we can decide how to move the topic forward together. > For now I implemented automatic submodules update using 'post-merge' hook. But obviously it does > not handle reset and things. I'm thinking of adding 'post-reset' and 'pre-merge' that would be useful > for this and maybe other things. I doubt hooks can be more than a band aid for submodule checkout. I thought about doing that too and came to the conclusion it will only handle some of the issues. And you'll have to provide a real life use case to get a new hook accepted ;-) -- 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