Re: [PATCH/RFC] Introduce git submodule add|update --attach

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

Francesco Pretto <ceztko@gmail.com> writes:

> by default "git submodule" performs its add or update operations on a detached
> HEAD. This works well when using an existing full-fledged/indipendent project as
> the submodule, as there's less frequent need to update it or commit back
> changes. When the submodule is actually a large portion of shareable code
> between  different projects, and the superproject needs to track very closely
> the evolution of the submodule (or the other way around), I feel more confortable
> to reattach the HEAD of the submodule with an existing branch.

I may be missing some fundamental assumption in your mind when you
did this change, but in a workflow where somebody wants submodule
checkout to be on branches (as opposed to detached), wouldn't it
make more sense not to detach in the first place, rather than
introducing yet another option to "re-attach"?  The documentation of
"submodule update" seems to say that its "merge" and "rebase" modes
do not detach in the first place (and it alludes to "--checkout" but
it is unclear what it does purely from the documentation, as "git
submodule --help" does not even list it as one of the options).

And if there is a good reason why detaching to update and then
(perhaps after verifying the result or cleaning it up?  I dunno what
the expected use case is, so I am purely guessing) attaching the
result to a specific branch in separate steps, does it make sense to
give "--attach" option to "update" in the first place?  That makes
the whole thing into a single step, not giving the user a chance to
do anything in between, which I am guessing is the whole point of
your not using the existing "do not detach, work on a branch" modes.

Puzzled...