[racket-dev] A story of a package split

40 minutes ago, Sam Tobin-Hochstadt wrote:
> On Tue, Aug 13, 2013 at 5:10 PM, Tony Garnock-Jones <tonyg at ccs.neu.edu> wrote:
> > On 08/13/2013 05:05 PM, Nick Shelley wrote:
> >>
> >> 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.
> >
> > One major difference I've just spotted is that git submodules are
> > tied to particular commit IDs, leading to detached-HEAD checkouts,
> > where a looser approach can check out subrepos on real branches.
> 
> Apparently this limitation has been lifted in the most recent git
> release.

Yes -- there is a `--remote' flag to `submodule update' which tells
git to grab whatever is current in the remote.  (On a branch that
eventually defaults to `master', but that can be configured.)  BTW,
there is also an `--init' flag which does the init if it wasn't done,
so if you use both:

    git submodule update --init --remote

you get all of the submodules in, using their current state.  And you
can use `git submodule status' to see if some submodule was updated
away from the recorded sha1.  One more issue is that this will still
have all the sub-modules in a detached head state (which is arguably
something that --remote should take care of), so instead of all of
this, you can just go into every submodule and checkout its master
explicitly:

    git submodule --init
    git submodule foreach git checkout master


(But all of this should be mostly irrelevant if the repositries are
really used as repositories -- rather than trying to force it into
looking like you still have a single monolithic repository.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!