Volker Hilsheimer (14 January 2021 10:50) wrote: > The init-repository script does some extra work that is supposed to > give people a leg up though, such as setting up commit hooks and > remotes in all submodules.
It also provides mechanisms for selecting what set of modules you want checked out. This means that I can, in my qt5/dev checkout, have a promiscuous selection of modules while, in each qt5/n.m checkout, I have n.m's essential, preview and addon modules checked out, based on init-repository's reading of n.m's .gitmodules files. I could surely do that using work-trees, all based off my primary qt5/dev repo and its sub-modules, but I'd want a straightforward way to automate it so that I can confidently be sure that my n.m work-tree contains everything that matters in n.m, rather than only the parts of it I happen to have worked on. > FWIW, I used it once, when I did the first clone, to do exactly that > kind of stuff. I never need it afterwards, and I rarely have to deal > with git submodules (and I’m not sure if it’s supposed to be used > afterwards), since I work in worktrees. And it sounds like worktrees are great for your workflows. So by all means let's document how to make good use of worktrees and, where appropriate, add tooling to support that workflow. Consider, however, that others have different work processes. Last year I enacted lots of outstanding // ### Qt 6 comments, many of which wanted deprecation and/or removal of methods, enum members and other random cruft. Of course, that meant I had to check for all modules using those things. For that, I needed a checkout that contains everything so that I could grep for mentions of the thing I was removing, to prepare the patches to other modules that would need to be taken in before I could deprecate or remove them from core. I also needed to do a build of everything, to try to catch any compilation fall-out that would result from things my grep didn't catch. (Things sometimes do stuff you can't anticipate, like synthesizing an enum name using a macro, so that grep never finds the name being used.) That mostly broke due to interdependency problems - I didn't know how to ask the system to synchronise using dependencies.yaml files, thanks for the recipe you gave today - but I guess I could fix it by taking a leaf-most module, getting everything consistent with its dependency.yaml and rebasing my qtbase removal change onto the selected qtbase revision, to do a test build; so at least I now know how to do this. (At the time I just used make -k and checked for which of the failures appeared to relate to my change. It wasn't very reliable.) For all of that, I needed all supported modules checked out somewhere, and I don't want to have to keep track of mailing list announcements to manual update the set of modules in my master repo. So we need some mechanism for automating checkout of "everything interesting" with some fairly sensible mechanism for identifying which things are interesting - which is going to vary between developers and, for any given developer, between work trees. So, before you throw out the whole supermodule, pause to answer how we're going to do the things that we currently can do, that some of us need, at least sometimes. On a related note, I agree that all the provisioning stuff for Coin belongs in a separate module: however, check with the Coin team for how to make that work in practice, since it's been suggested before and they had Reasons why it wasn't practical. Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development