On Thu, Jun 12, 2014 at 09:38:48AM +0200, Justus Winter wrote: > > I think I’ve already asked this one, but still: why not a Git > > submodule? > > Complexity. We are trying to reduce it. > > > One problem with the “merge ’em all” approach is > > that one can /add/ a thing to the repository, but one cannot > > really /delete/ it later. (In the sense that from that point > > on, the code added would remain in the Git history, – and be > > $ git clone’d forever.) > > In my head, that is exactly the point of a vcs, but ymmv. > > > On the contrary, submodules may be added and removed without any > > hassle. And from this point, I’d rather see Hurd – a collection > > of servers – living as a collection of Git repositories. > > I'd rather see the Hurd not being a major pain in the ass to develop, > but again, ymmv, as I guess it's a matter of perspective. > > > The only downside I could think of is that a single commit > > (unless made to the “upper level” repository) cannot really span > > multiple Git repositories. Which may be a problem as long as > > there’re strong interdependencies in the servers’ code. > > There are strong interdependencies, some are explicit, some are > implicit. And being able to change some aspects of the Hurd is part > of why I advocated this merge in the first place (as clearly stated in > my original mail).
I strongly agree with Justus on this. -- Richard Braun
