Re: [RFC v2] submodule: Respect requested branch on all clones

> On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:
> > The “gitlinked commits must be in the subproject's master” rule
> > protects you from blowing stuff away here.  You could use rebase- or
> > merge-style integration as well, assuming the maintainer didn't have
> > dirty local work in their submodule.
> 
> No we can't. Developers are not allowed to merge in some submodules.
> The most central ones have maintainers and only they are allowed to
> merge into the stable branch. So we need to track exact commits on the
> stable branch, no local merge (except the fast-forward case of course)
> allowed. Thats why the developer does an exact checkout here.

> > > We have a tool in our git gui configuration that does
> > > 
> > > 	git submodule foreach 'git fetch && git checkout origin/master'
> > 
> > I agree that with 'submodule update' seems superfluous.  With proper
> > out-of-tree submodule configs specifying remote URLs and upstream
> > branches,
> > 
> >   git submodule foreach 'git fetch && git checkout @{upstream}'
> > 
> > (or merge/rebase/…) should cover this case more generically and with
> > less mental overhead.
> > 
> > > I hope that draws a clear picture of how we use submodules.
> > 
> > It's certainly clearer, thanks :).  I'm not sure where checkout-mode
> > is specifically important, though.  In your step-2, it doesn't restore
> > your original branch.  In your “update the superproject's master”
> > step, you aren't even using 'submodule update' :p.
> 
> Ah sorry I though that was clear. The "others" are using submodule update ;-)
> 
> I mean someone who gets stuff from a stable superproject branch by
> either rebasing their development branch or updating their local copy of
> a stable branch (e.g. master) by using
> 
> 	git checkout master
> 	git pull --ff --ff-only
> 	git submodule update --init --recursive
> 
> This also prevents the pure "updaters" from creating unnecessary merges.