On Tue, Jan 14, 2014 at 11:19:07PM +0100, Heiko Voigt wrote:
> 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.

Because both sides of the merge/rebase are required (by your rule) to
be in the subproject's master, you're guaranteed to have a
fast-forward merge/rebase.

> > > 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.

Right.  Folks who don't do local development in their submodules can
get away with checkout-mode updates and their detached HEADs.
Assuming the upstream superproject only advances the gitlinked commits
using fast-forwards, they could equally well use any of the other
update modes, but there is no need for them to make that assumption.
*This* is the use case that I think the current recursive-checkout
facilitates [1].  I don't think it helps folks who are actually doing
submodule development on branches from within their superproject.

Cheers,
Trevor

[1]: http://article.gmane.org/gmane.comp.version-control.git/239695

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to