Am 04.04.2013 21:04, schrieb Linus Torvalds:
> My gut feel is that yes, .gitmodules was always a bit of a hack, but
> it's a *working* hack, and it does have advantages exactly because
> it's more fluid than an actual git object (which by definition has to
> be set 100% in stone).

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: automatically initialize and then populate
certain submodules during the clone of the superproject. You have to
be able to configure that per submodule, which needs a new config
option in .gitmodules. Others may follow for different use cases.

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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to