[racket-dev] proposal for moving to packages

On 05/21/13 12:21, Carl Eastlund wrote:
> On Mon, May 20, 2013 at 11:20 PM, Juan Francisco Cantero Hurtado <
> iam at juanfra.info> wrote:
>
>> On 05/20/13 23:24, Carl Eastlund wrote:
>>
>>> On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa <asumu at ccs.neu.edu>
>>> wrote:
>>>
>>>   On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
>>>>
>>>>> Eventually, when the dust settles, I think we'll want to convert every
>>>>> directory to its own git repo, and then we can incorporate the
>>>>> individual repos as git submodules.
>>>>>
>>>>
>>>> One nice thing about the current repo organization is that push
>>>> notifications for every part of the PLT codebase go to all of the
>>>> developers.
>>>>
>>>> Will that still be available in this organization scheme? (I don't care
>>>> if it's opt-in too much, but opt-out will hopefully mean more eyes see
>>>> the code)
>>>>
>>>> Cheers,
>>>> Asumu
>>>>
>>>>
>>> Overall, I'm really glad to see Racket moving into the package system.  I
>>> think it will be good for both (the Racket core and the package system).
>>> I'd like to mention, though, that git submodules can be a real pain for
>>> synchronizing development of multiple repositories.  They seem to have
>>> been
>>> designed primarily for importing upstream repositories, rather than for
>>> multiple "peer" repositories.  I'm not much more fond of the alternatives
>>> I
>>> have tried, either; if we're committing to splitting Racket into multiple
>>> repositories as well as multiple packages, we should be aware there may be
>>> another minor git learning curve ahead.
>>>
>>> Thanks to Jay and Matthew for working on all of this!
>>>
>>>
>> I also think that git submodules are a bad idea for packages. One git repo
>> per package is more simple and less problematic.
>>
>> Thanks for the hard work :)
>
>
> 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're going to use
> multiple repositories, we definitely need something like submodules in
> order to retain a shared commit history.
>

You're right. I was thinking in git subtree. Sorry for the confusion.