On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:
> 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.
> 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
Attachment:
signature.asc
Description: OpenPGP digital signature