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

Heiko Voigt [off-list ref] writes:

On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:

quoted

2014/1/5 W. Trevor King [off-list ref]:

quoted

On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:

quoted

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.

quoted

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