Re: A design for subrepositories

Jens Lehmann <Jens.Lehmann@web.de> writes:

You mentioned multiple things in your responses that you are planning to address, but I am wondering if the first step before doing anything else is to have a list of known-to-be-suboptimal things and publish it somewhere other people can find it. Then Lauri or others may able to help code the design of the approach to address them for items you already have designs for, and they may even be able to help designing the approach for the ones you don't.

More importantly, they do not have to waste time coming up with incompatible tools. Adding "works in this scenario that is different from those other slightly different tools" to the mix of third-party tool set would fragment and confuse the user base ("which one of 47 different tools, all of which are incomplete, should I use?") and dilute developer attention. They all at some point want to interact with the core side, and without an overall consistent design and coordination, some of their demand on the core side would end up being imcompatible.

The "just let .gitmodules record which branch is of interest, without checking out a specific commit bound to the superproject tree and using as a base for diff" (aka floating submodule) could be one of the items on the list, for example; to support it, we should not have to throw the entire "git submodule" with the bathwater.

Thanks.