Re: [PATCH 2/2] Introduce git submodule attached update

From: W. Trevor King <wking@tremily.us>
Date: Jan 7, 2014, 23:14 UTC
Message-ID: <20140107231404.GD26583@odin.tremily.us>
In-Reply-To: <20140107225128.GC10782@sandbox-ub>

On Tue, Jan 07, 2014 at 11:51:28PM +0100, Heiko Voigt wrote:

Show 24 quoted lines

> On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
> > Here's an attempted summary of our desires, and my ideal route
> > forward:
> > 
> > * Preferred local submodule branches for each superproject branch.
> >   * Not currently supported by Git.
> >   * Requires some sort of per-superproject-branch .git/config.
> >   * Fall back to the remote-tracking submodule.<name>.branch?
> > 
> > * Auto checkout of the preferred branch
> >   * Can do this at clone-update time with my patch.
> >   * For later submodule branch switches, maybe we want:
> > 
> >       git submodule checkout [-b <branch>] [<paths>…]
> > 
> >     Then if a user blows off their detached HEAD, at least they'll
> >     feel a bit sheepish afterwards.
> 
> Well, for development on a detached HEAD in a submodule we are currently
> not very careful anyway. A simple
> 
> 	git submodule update
> 
> will already blow away any detached HEAD work.

Only if you use the checkout strategy. With --merge or --rebase, you'll have the $sha1 (or upstream remote with --remote) integrated with your detached HEAD work. You end up with a new detached HEAD containing the result of the integration (just confirmed with tests using Git v1.8.3.2). That seems reasonable to me, so I'm happy with the integration logic.

> But AFAIK it should trigger the "you are leaving commits from a
> detached HEAD behind" warning, so there is some safeguard and
> recovery.

I did not see those in testing with Git v1.8.3.2, likely because of the '-f -q' we pass to 'git checkout' for checkout-mode updates.

Regardless of branch integration issues, I think a per-superproject-branch preferred submodule branch is important for 'git checkout' to work in the superproject. If you want:

* submodule branch master for superproject branch master, and
* submodule branch my-feature for superproject branch my-feature,

  $ git checkout my-feature

in the superproject is currently going to leave you with the submodule on master, which is not convenient ;). I think we should come up with a better solution to the superproject checkout problem before adding in additional complications due to branch integration ;).

Cheers, Trevor

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