40 minutes ago, Sam Tobin-Hochstadt wrote:
> On Tue, Aug 13, 2013 at 5:10 PM, Tony Garnock-Jones <to...@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!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
