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

From: W. Trevor King <wking@tremily.us>
Date: Jan 14, 2014, 21:42 UTC
Message-ID: <20140114214209.GJ23617@odin.tremily.us>
In-Reply-To: <20140114205830.GA838@sandbox-ub>

On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:

Show 12 quoted lines

> A typical workflow where a feature in a project needs some extension or
> change in a submodule goes like this:
> 
> 1. The developer does his changes locally implementing everything
>    needed. To commit he creates a local branch in the submodule and in
>    the superproject (most of the times from the current HEAD that is
>    checked out).
> 
> 2. For convenience I usually commit the resulting commit sha1 of the
>    submodule in the commit that needs the change. That way when I switch
>    to a different branch and back I can simply say: git submodule update
>    and get the correct code everywhere.

This checkout functionality is exactly what my submodule.<name>.localBranch is designed to automate [1]. I think that should be different from integrating local and external changes, which is what 'git submodule update' is about. For example, after you run 'git submodule update' here, you'll have your original commit checked out, but you'll be on a detached HEAD instead of your original branch. If you want to further develop the submodule feature branch, you currently have to cd into the submodule and check the branch out by hand.

Show 12 quoted lines

> How about the use-case I sketched above? Is that what you are searching
> for? In that use-case we have to update to the new master after a
> submodule change was merged. That could be achieved by
> 
> 	git submodule update --remote <submodule>
> 
> with the wanted stable branch configured. But in practise something
> along the lines of
> 
> 	(cd <submodule> && git checkout origin/<stable>)
> 
> is usually used and simple enough.

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.

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

Cheers, Trevor

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

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