Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > Am 05.06.2011 20:27, schrieb Junio C Hamano: >> If you think about "absense of the remote in the superproject means the >> project originates from here", what you are doing in step 3. is to >> changing the origin of these set of projects. After changing the origin of >> these set of projects, isn't "git submodule sync" an established way to >> adjust to the change? I was hoping that that would update .git/config in >> step 3. so you wouldn't have the problem in step 4. at all. > > Thanks for explaining that in detail, I think I do get it now. I actually still have a feeling that I may be missing something from the discussion. While I do like a solution that lifts existing limitation to allow workflows that were hitherto impossible, that only makes sense when the newly allowed workflow makes sense and useful, and when the lifted limitation was not protecting some silly mistakes from getting made. I _think_ our last exchange gave me a fuzzy confirmation that we are not lifting a useful limitation, but I still do not know if the new workflow matches the workflow Marc (who kicked off this thread) wanted to use. I think it does match the set-up Phil Hord mentioned in an earlier message, though. -- 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