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

> -----Original Message-----
> From: Junio C Hamano
> Sent: Tuesday, May 10, 2022 1:01 PM
> To: Addison Klinke <addison@baller.tv>
> 
> Addison Klinke <addison@baller.tv> writes:
> 
> > Is something along these lines feasible?
> 
> 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.