From: Junio C Hamano <firstname.lastname@example.org>
To: Addison Klinke <email@example.com>
Cc: firstname.lastname@example.org, Addison Klinke <email@example.com>
Subject: Re: [FR] supporting submodules with alternate version control systems (new contributor)
Date: Tue, 10 May 2022 10:00:52 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <CAE9CXuhvqfhARrqz2=oS1=9BF=iNhGbJv7y3HmYs1tddn8ndiQ@mail.gmail.com> (Addison Klinke's message of "Tue, 10 May 2022 10:11:48 -0600")
Addison Klinke <email@example.com> writes:
> Is something along these lines feasible?
Offhand, I only think of one thing that could make it fundamentally
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
* 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
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 ;-).
next prev parent reply other threads:[~2022-05-10 17:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 16:11 Addison Klinke
2022-05-10 17:00 ` Junio C Hamano [this message]
2022-05-10 17:20 ` Jason Pyeron
2022-05-10 17:26 ` Addison Klinke
2022-05-10 18:26 ` rsbecker
2022-05-10 20:54 ` Philip Oakley
2022-06-01 12:44 ` Addison Klinke
2022-06-03 23:06 ` Philip Oakley
2022-06-04 2:01 ` rsbecker
2022-06-04 13:27 ` Philip Oakley
2022-06-04 15:57 ` rsbecker
2022-06-05 21:52 ` Philip Oakley
2022-06-06 14:53 ` Addison Klinke
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this inbox:
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).