Re: [FR] supporting submodules with alternate version control systems (new contributor)

Addison Klinke <addison@baller.tv> writes:

Offhand, I only think of one thing that could make it fundamentally infeasible.

When you bind an external repository (be it stored in Git or somebody else's system) as a submodule, each commit in the superproject records which exact commit in the submodule is used with the rest of the superproject tree. And that is done by recording the object name of the commit in the submodule.

What it means for the foreign system that wants to "plug into" a superproject in Git as a submodule? It is required to do two things:

 * At the time "git commit" is run at the superproject level, the
   foreign system has to be able to say "the version I have to be
   used in the context of this superproject commit is X", with X
   that somehow can be stored in the superproject's tree object
   (which is sized 20-byte for SHA-1 repositories; in SHA-256
   repositories, it is a bit wider).

 * At the time "git chekcout" is run at the superproject level, the
   superproject will learn the above X (i.e. the version of the
   submodule that goes with the version of the superproject being
   checked out).  The foreign system has to be able to perform a
   "checkout" given that X.

If a foreign system cannot do the above two, then it fundamentally would be incapable of participating in such a "superproject and submodule" relationship.

Everything else I think is feasible in the sense that "it is just a matter of programming".

It is a different story how it is implemented, how much it would cost to do so, and if it is worth maintaining it as part of Git, so I'd stop at "is it feasible?" here, not judging "if it is realistic" at this point ;-).