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

From: Heiko Voigt <hvoigt@hvoigt.net>
Date: Jan 14, 2014, 22:19 UTC
Message-ID: <20140114221907.GC838@sandbox-ub>
In-Reply-To: <20140114214209.GJ23617@odin.tremily.us>

On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:

Show 23 quoted lines

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

Yes and thats exactly what my idea was about but after further thinking am afraid that this is the wrong place. I am not sure but afraid as I wrote in the other post that it would be way to dangerous to accidentally merge these changes in. We would need something to prevent this configuration from ever entering a stable branch.

Another solution (and completely different approach) would be to have something that is outside of the tree and actually attached to a branchname. E.g. at the gitmerge last year I though it would be nice to have a place for a description for a branch inside git. In a short discussion we were envisioning a special ref like the notes trees but allowing to attach and describe branches. That place could also be where we could store such a configuration. Once the branchname ceases to exist so would the configuration.

I know this is a completely different piece of work so I am not sure whether we want to pursue it at the moment. But at the moment I think this would actually be the correct solution.

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

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.

Show 19 quoted lines

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

Cheers Heiko

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