Hi Gary, > ... entirely sufficient for: > > 1. running on a freshly cloned working copy to set everything up ready for > ./configure && make > > 2. rebootstrapping after updating submodules
Yes, it is sufficient for the "simple" cases. What the current bootstrap is not good at: * Keeping the developer in control of git. When I am a developer, I may want to control precisely which version of the submodule I want to use. For example, if I am about to make a release, I may want to pull some but not all recent commits from the submodule. Or I may want to try changes that are not yet committed. As the maintainer of a package I may want to run all git commands by myself (and remember what I've done), rather than have some script do it for me. * Hiding the 'git submodule' complexity from the developer. Everyone is familiar with the basic commands of git. But 'git submodule' is a different set of commands with a different philosophy. And its own set of pitfalls [1]. You may say that these two goals are incompatible. I disagree. - To fulfil the first goal, it is sufficient to move all git operations to a separate script. - To fulfil the second goal is an art. But just like 'gnupload' allows me to forget how to invoke 'gpg', why would that separate script now allow to forget me how to invoke 'git submodule'? Bruno [1] https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/