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

>Thanks for the quick replies
>
>> Junio Hamano: 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.
>
>This should be fine then - at least the data versioning tools I'm familiar with can all
>specify their current commit and checkout by commit hash. Does it matter how
>the hashes are structured/stored internally? For example, I believe Dolt keeps
>them in a MySQL table that connects to Noms under the hood.
>
> > Junio Hamano: not judging "if it is realistic" at this point
>
>What would be the best approach for answering this portion?

>> Jason Pyeron: The submodule "type" could create an object (hashed and
>> stored) that contains the needed "translation" details
>
>That sounds like an interesting idea. Since I'd like to offload the burden of
>maintaining these translation files to the 3rd party developers, it would be nice if
>they got copied to a standard location (i.e. ~/.gitmodules/translations/tool_x)
>during the 3rd party install.
>Then when a submodule is added with "type = tool_x", git checks that the
>appropriate translation file is available, and if so, copies it into the parent
>repository.
>
>On Tue, May 10, 2022 at 11:20 AM Jason Pyeron <jpyeron@pdinc.us> wrote:
>>
>> > -----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.
>>
>> The submodule "type" could create an object (hashed and stored) that contains
>the needed "translation" details. The object would be hashed using SHA1 or
>SHA256 depending on the git config. The format of the object's contents would be
>defined by the submodule's "code".