Andy Parkins <andyparkins@xxxxxxxxx> writes: >> As you fix them and enhance the support, I suspect you would >> want a separate command to manage .gitmodule file and submodules >> referenced by it. I think it would be better to keep the patch >> to the template to the minimum (for example, run "git submodule >> update" if there is .gitmodules file at the toplevel), and >> implement the body of the processing in "git-submodule.sh", or >> something like that. > > That's an interesting idea. I was thinking that git-commit > itself would have been the final target; but I certainly don't > have any problem with a separate command. I do not think the commit command would be the "final" one. When you have a loosely coupled subproject, sometimes you might want to check out subprojects recursively, so you would also want "checkout" action to "git submodule", which might hook into "git checkout" just like your patch hooked into "git commit". Similarly your future versions certainly would want to hook into "git fetch/pull". Just like some peoples' workflow avoid "git pull" but do "git fetch" and "git merge" as separate steps, some people may want to disable the above "hooks", and prefer using "git submodule" from the command line as a separate step, especially if they want very loose coupling. - 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