<div dir="ltr">On Tue, Jun 4, 2013 at 7:05 PM, Austin Seipp <span dir="ltr">&lt;<a href="mailto:aseipp@pobox.com" target="_blank">aseipp@pobox.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know we had this discussion sometime recently I think, but can<br>
someone *please* explain why we are in this situation of half<br>
submodules, half random-floating-git-repository-checkouts? It&#39;s<br>
terrible. I&#39;m frankly surprised we&#39;ve even been doing it this long,<br>
over a year or more? It is literally the worst of submodules, and<br>
free-standing-repositories put together, with none of the advantages<br>
of either.<br></blockquote><div><br></div><div style>This is my understanding of what happened: we started out with only plain repos. This avoids some of the pitfalls of submodules and we believed it was the least disruptive workflow (when switching form darcs) for the core contributors. Eventually we needed GHC to track upstream releases of libraries (e.g. Cabal) instead of jus tracking HEAD, which it did before. To achieve that, we switched the libraries that GHC just tracks (e.g. Cabal) to submodules. The libraries maintained by GHC HQ (e.g. base) we&#39;re still kept as plain repos to avoid disrupting anyones workflow.</div>

<div style><br></div><div style>The latest git release has improved submodules support some so if we now thing the benefits of submodules outweigh the costs we can discuss if we want to change to policy. I don&#39;t want to make that decision for other GHC developers that spend much more time on GHC than I (e.g. SPJ). Their productivity is more important than any inconveniences the lack of consistent use of submodules might cause me. </div>

</div></div></div>