[racket-dev] A story of a package split

Although I like being right, I'm not sure what I'm right about. We use
submodules at work both to include third-party tools and to share code
among related internal projects. Submodules have worked fine for us so far,
but they also have their downsides. For instance, we've made changes to
shared submodules in one project and then not updated in other projects for
a while, only to realize when we do update that those changes didn't work
in the other project, so we had to make fixes to both (I just reread that
sentence and realized it's pretty mumbly, but I'm too lazy to reword it).

I was mainly asking about the intermediate form because it seems like it
could be useful, but I didn't understand how it would work.


On Tue, Aug 13, 2013 at 2:49 PM, Tony Garnock-Jones <tonyg at ccs.neu.edu>wrote:

> On 08/13/2013 04:42 PM, Nick Shelley wrote:
>
>> Can you elaborate on your intermediate form? I don't understand how git
>> submodules prohibit or restrict submodule evolution. The only difference
>> I see with the submodule approach is that it requires an extra commit to
>> update the submodule versions (and subsequently a pull followed by a
>> submodule update in other clones), whereas the makefile approach only
>> requires a 'make update' in the umbrella clones. Is there something else
>> I'm missing?
>>
>
> Perhaps you're right. Maybe my impression that git submodules are frozen
> is out-of-date. It has been a while since I used them. Perhaps they're
> first-class checkouts that can be manipulated independently of their...
> supermodule. If that's true, perhaps they're an OK way of specifying a
> versioned subrepo manifest.
>
> Cheers,
>   Tony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130813/dd25c48f/attachment.html>