On 1/14/15 12:18 PM, H. S. Teoh via Digitalmars-d wrote:
If you set up a
"super-repo", it would look something like this:
dlang/ # root git repo
dmd/ # git submodule referencing the dmd repo
druntime/ # git submodule referencing the druntime repo
phobos/ # git submodule referencing the phobos repo
dlang.org/ # git submodule referencing the dlang.org repo
Then checking out this new dlang repo (with the requisite git flags)
will create the above structure for you, including clone all the
sub-repos. *This* is what will address point (2) that I raised earlier:
the user shouldn't need to manually setup some arbitrary directory
structure for you -- automate this with git submodules instead!
Agreed. Ah, this is getting interesting, thanks. So I've wanting to look
into submodules for a while now but have been discouraged by the bad
press they seem to be getting:
https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
http://ayende.com/blog/4746/the-problem-with-git-submodules
http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/
http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/
(though I have no idea whether what's relevant for puppet is relevant to us)
Having such a super-repo will also solve the problem of git bisecting
earlier toolchain releases -- because the super-repo references the
sub-repos by SHA hashes, which are history-tracked by git, so we could
set it up so that each commit of the super-repo corresponds with a valid
version set of dmd/druntime/phobos. Then you could checkout a specific
commit of the super-repo and update git submodules, and you'll get a
snapshot of the entire toolchain as it stood at the time of the commit.
If we do this right, we could even have the autotester update the
super-repo automatically upon successful completion of the test suite
for the entire toolchain.
And ideally, stuff common to multiple subrepos should be in this
"super-repo", such as the stuff you're trying to factor out right now.
Including the master makefile that will build everything WITHOUT needing
to reference out-of-tree paths. And ideally, any out-of-tree references
needed by the subrepos will be via configurable parameters (e.g. $(DMD),
$(DRUNTIME_PATH), etc.), which the master makefile can set to the
correct values, so the subrepos don't have to know or hardcode where the
exact out-of-tree location ought to be.
Such a super-repo will also make release management easier: instead of
manually managing release tags in each of dmd/druntime/phobos, we can
tag the super-repo, which encapsulates the exact set of
dmd/druntime/phobos commits for that release.
I hear you but The Internet says submodules are a kind of a bummer.
Andrei
