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

[Junio C Hamano <gitster@pobox.com>]

Heiko Voigt <hvoigt@hvoigt.net> writes:

> On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
>> 2014/1/5 W. Trevor King <wking@tremily.us>:
>> > On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
>> >> Also it could break some users that rely on the current behavior.
>> >
>> > The current code always has a detached HEAD after an initial-clone
>> > update, regardless of submodule.<name>.update, which doesn't match
>> > those docs either.
>> 
>> I perfectly agree with you that the documentation is a bit
>> contradictory with regard to "update" command and detached HEAD.
>> That's why it's so hard to add a feature and keep the same spirit of
>> those that coded submodules at first. Also, I think that submodules
>> didn't get much feedback with regards to these pitfalls because many
>> people try to setup them, they see that "update" detaches the HEAD and
>> they think "hmmm, maybe submodules are not what I was looking for".
>
> I am not so sure about that. Why should detached HEAD make you think
> like that? For us at $dayjob we have a pre-commit hook that denies you
> to commit on a detached HEAD and asks you to create a branch first.

Perception is irrational ;-)

We long-timers think detached is a perfect starting point for both
users of submodule who merely want to use the specified commit and
developers who want to work on the submodule to match the need of
the superproject.  The former do not have to do anything, and the
latter will have to chdir to the submodule working tree and create a
branch (or update the branch with rebase or pull on top of the
specified commit) as the first thing before doing anything.

Not everybody is a long-timer, but the saving grace is that nobody
stays a newcomer.

BUT.

>> - developers checkout that commit and don't pull (you can't do "git
>> pull" in a detached HEAD);
>
> Exactly. We consider pull evil ;-) Seriously: To update we only do fast
> forward merges of local stable branches. 
> ...
> 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.  If that is not how it is
supposed to work, please correct me---and we may have to add another
mode that does so (or even make rebase/merge do so as a bugfix).

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?