<div dir="ltr">On Mon, May 20, 2013 at 11:20 PM, Juan Francisco Cantero Hurtado <span dir="ltr">&lt;<a href="mailto:iam@juanfra.info" target="_blank">iam@juanfra.info</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"><div><div>On 05/20/13 23:24, Carl Eastlund wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa &lt;<a href="mailto:asumu@ccs.neu.edu" target="_blank">asumu@ccs.neu.edu</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Eventually, when the dust settles, I think we&#39;ll want to convert every<br>
directory to its own git repo, and then we can incorporate the<br>
individual repos as git submodules.<br>
</blockquote>
<br>
One nice thing about the current repo organization is that push<br>
notifications for every part of the PLT codebase go to all of the<br>
developers.<br>
<br>
Will that still be available in this organization scheme? (I don&#39;t care<br>
if it&#39;s opt-in too much, but opt-out will hopefully mean more eyes see<br>
the code)<br>
<br>
Cheers,<br>
Asumu<br>
<br>
</blockquote>
<br>
Overall, I&#39;m really glad to see Racket moving into the package system.  I<br>
think it will be good for both (the Racket core and the package system).<br>
I&#39;d like to mention, though, that git submodules can be a real pain for<br>
synchronizing development of multiple repositories.  They seem to have been<br>
designed primarily for importing upstream repositories, rather than for<br>
multiple &quot;peer&quot; repositories.  I&#39;m not much more fond of the alternatives I<br>
have tried, either; if we&#39;re committing to splitting Racket into multiple<br>
repositories as well as multiple packages, we should be aware there may be<br>
another minor git learning curve ahead.<br>
<br>
Thanks to Jay and Matthew for working on all of this!<br>
<br>
</blockquote>
<br></div></div>
I also think that git submodules are a bad idea for packages. One git repo per package is more simple and less problematic.<br>
<br>
Thanks for the hard work :)</blockquote><div><br></div></div>Git submodules imply one repo per package.  A submodule is a mechanism that imports external repos into a checkout of a client repo, and records the specific commit of the checkout so that there is a correlation of the commits in each repo stored with the client.  If we&#39;re going to use multiple repositories, we definitely need something like submodules in order to retain a shared commit history.<br>


<br></div><div class="gmail_extra">--Carl<br></div></div>