how to checkout proper submodules

[Austin Seipp]

On Wed, Jun 5, 2013 at 10:20 AM, Daniel Trstenjak
<daniel.trstenjak at gmail.com> wrote:
> I think subtree has been part of git since 1.7.x .
>
> I have just installed the default git package (git 1.8.1.2) of Ubuntu
> 13.04 and the subtree command is just there.
>

It's *part* of mainline git, but it is not installed with git. It's
part of git's "contrib" functionality package which requires that your
package maintainer be gracious enough to include it and install it by
default, which requires extra intervention at build-time.

As a counter-example, my 'git' from Ubuntu 12.04 LTS machine has no
subtree and there are no existing instances of it in any 'precise'
repositories. I'm hesitant to require developers en masse to use it
for reasons like this.

(Frankly I also don't know how this would work out on windows. Like, I
don't know how to get a git-build-with-subtree-for-windows, much less
if it works on windows at all.)

> Sorry that I'm not aware of the GHC development process, but why are
> the testsuite and base in separate repositories?

Because GHC does not technically 'own' them by the most strict
definition. testsuite and base are also useful for other compilers,
such as nhc98 (and indeed, nhc uses base itself.) The same can be said
of nofib. As a result, there is a separation.

Now, in practice everybody working on base is a GHC hacker pretty
much, and ditto with testsuite/nofib. Regardless of all that, to
change *this* part of the equation is a much, much bigger argument.
One I don't intend to wage at the moment.

> submodules are fine for tracking repositories, but if you're all the
> time changing multiple submodules, than it's a sign that you've a
> strong dependency between the repositories, so why not just having
> one repository?

I would agree. In practice many of the submodules are touched
extremely rarely - one change every several months. Sometimes, no
changes at all between entire releases spanning a year. testsuite and
base are definitely the exception, but they are also what most people
spend their time with in terms of hacking (pareto in action; 80% of
peoples work, 20% of the code.)

But again, to change this is a far larger argument with historical
implications, and implications beyond GHC. Malcolm would certainly
have input as he maintains nhc. (In the past, from my understanding,
nhc etc were more prevalent. But over time we've moved more and more
to GHC, and 'cruft' has arguably lingered.) I think folding base and
testsuite into GHC 'for good' is a separate discussion entirely.

> Isn't this more a build system issue, that you're able to specify what
> should/shouldn't be build, than a repository issue?

Yes. It is not insurmountable, my point is more it's an immediate loss
for some small reasons, but really nothing more than a minor
annoyance. It's just something to remind people of, should we make the
change.

> Greetings,
> Daniel
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



-- 
Regards,
Austin - PGP: 4096R/0x91384671