Hi, On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote: > I will write another post about how I think we should/can proceed.
and here is my suggestion how we should proceed. I think there have been many interesting ideas in this thread but IMO some of them tried to achieve a little bit to much and were not clear enough. I am a fan of: Keep it as simple as possible, but *no simpler*. I think some ideas where going in the "make it to simple" direction. Take my idea for feature branch support from here. After thinking more thoroughly it still too many corner cases. E.g. it is way to easy to accidentally merge the feature branch configuration into the stable branch. But we want to support the user properly so we need to catch stuff like that. Submodules are separate projects. There is a boundary between superproject and submodule and IMO its there for a good reason. E.g. take the typical "shared code" use-case. If A and B are using C then both want to make sure a change from A does not break B's expectations and vice versa. Thats were you usually write unit tests in C for: Ensure that the expectations are met. The more users of the code the higher the quality and thus the boundary for bad code should be. I would like to step back a bit and get back to the original problem at hand: Francescos original use case of an attached head for direct commits on a stable branch in a submodule. How about we finish discussing the exact solution of that first. AFAIK that is already solved with the following: * Trevor's first patch to create a branch on initial clone of a submodule * A possibly a configuration variable for --remote so it can be set as the default update method * Combined with submodule.<name>.update=merge/rebase That should be all (and IIRC Francesco agreed) needed for that use-case. Lets not implement more than currently is needed. We can revisit the ideas once some other real use-case manifests. Also we (Jens and I) would first like to proceed with the recursive checkout / fetch (for which the plan is clear) as the next complicated step. Once that is done and people gain some experience with it we can still extend further. What do you think? Cheers Heiko  http://article.gmane.org/gmane.comp.version-control.git/240178/  http://article.gmane.org/gmane.comp.version-control.git/239921 -- 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