2014/1/5 Heiko Voigt <hvo...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
