Am 06.06.2011 23:23, schrieb Marc Branchaud: > On 11-06-06 05:00 PM, Junio C Hamano wrote: >> 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. That's why I started with an improved error message and documentation ;-) >> 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. > > Well, Jens's changes do remove the error I encountered, and they also do what > I was expecting in the original context I was in when I started this thread. > So I think this is a definite improvement. Thanks. > There may still be a lingering niggle where git might do something the user > doesn't expect. For example, git might create a submodule out of > git://origin/foo.git instead of the local ../foo.git. You have to be paying > attention to git's output to notice that difference, and I could see where a > user might get tripped up. But IMO improving this can be done independently > of Jens's patches. Maybe Phil's opinion could be helpful here as he seems to be a heavy user of relative submodule urls. -- 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