A report from the junior varsity squad: I just tried this on OS X and it worked AOK.
FWIW I've been strictly doing `git pull --ff-only upstream master` to keep my fork's master 100% in sync with PLT's. Any experimentation or feature requests done solely on topic branches. (Like I wrote about here: http://www.greghendershott.com/2013/04/a-guide-for-infrequent-contributors-to-racket.html ) I don't yet know enough about Git submodules to understand the analog of that workflow for submodules, if any. I suspect it will be moot because I'll probably never doink around with the kind of stuff in native-pkgs. However if submodules start to get used more extensively I guess I may need to learn more about submodules. On Sat, Jul 27, 2013 at 9:10 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > Nothing has been split out of the current git repository, but there is > now a "native-pkgs" git submodule for the native-library packages. > > If you build on Mac OS X or Windows or if you run a snapshot build, > then you'll need to use > > git pull > git submodule init > git submodule update > > once on each repository checkout from now on, and > > git pull > git submodule update > > for updates after the first checkout. > > If you just `git pull' without the submodule commands, then you'll have > an empty "native-pkgs" directory. That's fine if you're building on, > say, Linux. If you're on Mac OS X or Windows, then the makefile should > give you a good error message and suggest using `git submodule init' > and `git submodule update'. > > If you use `git submodule update' today and forget to use it in the > future, probably things will be fine for a long time, because > "native-pkgs" doesn't change often. If "native-pkgs" does change and > you forget `git submodule update', then (as I understand things) `git > status' will tell you that there's a mismatch. The mismatch report > might take a form that's not entirely clear, but it should be enough to > remind you to run `git submodule update'. > > > I'm still unsure that submodules are going to be useful for managing a > kind of "main-distribution" repository with references to package > repositories. I'm much more confident that a submodule will work for > the native-library packages in the current build structure. The native > libraries are already kept in a separate repository, they change > infrequently, and almost no one has to change them. Also, the > "native-pkgs" git submodule replaces two things that I think were just > bad forms of `git submodule update': > > * A makefile target that fires on Mac OS X and uses `git pull', which > is bad if you happen to be working offline. > > * A note in "INSTALL.txt" that tells Windows users to manually clone a > particular git repository. > > If a git submodule does not work out for native-library packages after > all, then should be easy to roll back, since there was no split to > rewind. Meanwhile, we get a little experience with git submodules. > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev
