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
signature.asc
Description: OpenPGP digital signature
