On Mon, Jan 06, 2014 at 08:56:22AM -0800, Junio C Hamano wrote:
> Heiko Voigt <hvo...@hvoigt.net> writes:
> > Yes, why would you do a git pull in a submodule? Don't you want to do
> > something like
> >
> >     git checkout -t -b dev/my-topic origin/master
> >
> > to start your development?
> As long as origin/master contains the commit specified by the
> superproject, that would work, but it may be a good thing to use a
> mode of submodule.*.update that does not have to drop the user into
> a detached state in the first place.  I somehow thought that was
> what rebase (or merge) was about, that is, starting from the state
> where a branch is checked out in the submodule working tree, an
> update in the superproject would cause that branch checked out in
> the submodule brought up to date with respect to the commit
> specified in the superproject tree.

That is my understanding as well.  In fact, I don't think the
detached-HEAD-vs-branch distinction is important here, you can still
rebase your detached HEAD onto the superproject's referenced commit
(or origin/$branch with --remote).  This will also work for merge, and
should work for well-crafted !commands.

> And wouldn't it make it unnecessary to have a new "re-attach" option
> if such a mode that never have to detach is used?

I think so, but we currently don't have a "never detached" route for
folks that are cloning submodules via update (instead of via
'submodule add').  Currently, new clone-updates will always leave you
with a detached HEAD (unless you have branch-creation in your update
!command).  My patch aims to close this detached-HEAD gap, for folks
we expect will be doing local development, by creating an initial
branch at clone-update time.


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

Reply via email to