2014/1/6 Junio C Hamano <gitster@xxxxxxxxx>:
>
> 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).
>
I think the mode you are referring to is actually my
"submodule.<name>.attached" property. As I said to Heiko, the
"submodule.<name>.attached" property says two things:
- at the first clone on "git submodule update" stay attached to
"submodule.<name>.branch";
- implies "--remote", as it's the only thing that makes sense when the
submodules are attached.
> 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 the reattach|detach option are still needed (it is debatable
if we should have something like "git submodule head" command or we
can keep them in "git submodule update") because the user may want to
do so and doing it requires things should be really atomic:
* fix the head state;
* set the local .git/config "submodule.<name>.attached" property.
The "--attach" switch also can add a great bonus: it can reintegrate
orphaned commits when reattaching and having a "update" mode with
"merge" or "rebase". This is already in my patch.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html