Re: [PATCH 2/2] Introduce git submodule attached update

[Francesco Pretto <ceztko@gmail.com>]

2014/1/5 Heiko Voigt <hvoigt@hvoigt.net>:
>
> Could you please extend the description of your use-case so we can
> understand your goal better?
>

Just in case you missed the first patch iteration[1].

> The following questions directly pop into my mind:
>
>  - What means the maintainer does not track the submodules sha1? Does
>    that mean the superproject always refers to submodule commits using
>    branches?

It means he doesn't need to control other developers commit to be
checked out so he sets "submodule.<name>.ignore" to "all". In this way
he and the developers can work actively in their submodule copy.

>  - What happens if you want to go back to an earlier revision? Lets say
>    a tagged release? How is ensured that you get the correct revision in
>    the submodules?

"submodule.<name>.branch" is one setting that is not copied in
".git/config" by "git submodule init". "git submodule update" will use
the setting in ".gitmodules" if not overridden voluntarily by the
developer in ".git/config". The maintainer can change that setting in
".gitmodules" and commit the change. Modifies will be propagated by
the next "git pull && git submodule update" of the developer in the
superproject.

>  - In which situations does the developer or maintainer switch between
>    your attached/detached mode?

The developer/maintainer does so optionally and voluntarily and it
effects only its private working tree.

>  - What is the "repository branch" which is given to the developer by
>    the maintainer used for? Who creates this branch and who merges into
>    it?

The branch of course must exist prior submodule adding. In this
use-case it does not really matter who creates it and who merges into
it. Everyone with the right to merge into it has to work in the
submodule seamlessly, as it was working on separate clone of the same
repository used as the submodule.

>  - What are these subsequent "merge" or "rebase" update operations? Do
>    you mean everyone has submodule.name.update configured to merge or
>    rebase?
>

subsequent "merge" or "rebase" update operations are just the ones
after the initial clone/checkout, nothing particular.

Greetings,
Francesco

[1] http://marc.info/?l=git&m=138836829531511&w=2