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. 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
signature.asc
Description: OpenPGP digital signature
