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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html