[Development] Qt6 repo

[Edward Welbourne]

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.