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

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:

quoted

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.

quoted

quoted

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.

quoted

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