On Friday 25 May 2007, Johannes Schindelin wrote: > On Fri, 25 May 2007, Josef Weidendorfer wrote: > > * Submodules can appear/disappear any time in the superproject. > > Therefore, going back in time can make it necessary to have to clone > > a submodule you did not have before. > > * Not every submodule is interesting for every developer; therefore, > > an important design-decision for submodules is to allow at git-clone time > > to not clone some submodules at all. However, you can change your mind and > > want to follow a given submodule later. > > Okay, so there are exceptions to the rule, just as everywhere. The question here is in how many superprojects the exception will become the rule, which would make manual overriding quite cumbersome. However, the exact policy for finding a fitting URL for a submodule is not a fundamental design decision, and can be incrementally improved, depending on use cases. I agree with Junio that a simply, basic and robust submodule implementation currently is important as first goal. > We should not design for the exception. Therefore I think the .gitmodules, > overrideable by .git/config is sufficient. > > And the point about my config being private still stands. You have no > business looking into my config. I totally agree. Josef - 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
