On Sun, Jan 05, 2014 at 03:50:49AM +0100, Francesco Pretto wrote: > At the current state, the following use-case is not supported very > well in git: > - a maintainer adds a submodule, checking out a specific branch of > the repository. He doesn't track the upstream submodule revision sha1; > - a developer checkout the repository branch decided by the maintainer. > Subsequent "merge" or "rebase" update operations don't detach the HEAD. Could you please extend the description of your use-case so we can understand your goal better? 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? - 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? - In which situations does the developer or maintainer switch between your attached/detached mode? - 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? - What are these subsequent "merge" or "rebase" update operations? Do you mean everyone has submodule.name.update configured to merge or rebase? Still puzzled. Cheers Heiko -- 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