In response to an email Nathan wrote:
Submodules seem to be meant for including a project you're not
working on, just >referencing (i.e. a library).
dlang-workspace is built for contributors for D in mind, so
there will be a lot >of forking/branching, something submodules
to not handle well.
I'm not experienced in this though, so tell if I'm wrong.
Thanks,
NMS
Wrong, all submodules will do is store the hash for each repo.
This is really good because even with projects you work on you'll
require all three (Phobos, druntime, dmd) to be in a specific
version that is compatible with your changes. It does mean that
by default you are unlikely to check out the latest of all three
(since I doubt you'll be updating the repo for that.
However, consider the developer here. They are making some
changes, then need to test a pull request, this pull request uses
a newer version of dmd. They will then be able to commit all
their changes including the current commit of the dependent DMD,
checkout the new development branch with whatever version of dmd
is needed. When testing is done they checkout their branch update
the submodules and continue their work updating and testing dmd
when ready for the pull request.
It does actually make it more complicated as to get the latest it
would be:
$ git submodule update --init
$ cd dir
$ git --rebase pull
...
But really a utility can have that: ./latest.sh
