Jens Lehmann wrote: > Exactly. The flexibility of the .gitmodules file will really help us > when it comes to the next feature that submodules are going to learn > after recursive update: That's like saying that the flexibility of a blob is invaluable: let's throw out all the other objects, and make do with blobs. Ofcourse we make mistakes: we didn't put a generation number in the commit object, for instance (I'm not arguing about whether it's right or wrong: just that some people think it's a mistake). > While starting to grok submodules I was wondering myself if the data > stored in .gitmodules would better be stored in an extended gitlink > object, but I learned soon that the scope of the data that has to be > stored there was not clear at that time (and still isn't). So I'm > not opposed per se to adding a special object containing all that > information, but I strongly believe we are not even close to > considering such a step (and won't be for quite some time and maybe > never will). Nonsense. We will think through it before freezing the format, like we did with the other objects. -- 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