From: skillzero@gmail.com
To: git@vger.kernel.org
Subject: Re: Why do git submodules require manual checkouts and commits?
Date: Sun, 18 May 2008 21:38:16 -0700 [thread overview]
Message-ID: <2729632a0805182138s3e268cdbxd0d7c42bbcf01f84@mail.gmail.com> (raw)
In-Reply-To: <32541b130805160643y3bfe609et22b2d00627f98c04@mail.gmail.com>
On Fri, May 16, 2008 at 6:43 AM, Avery Pennarun <apenwarr@gmail.com> wrote:
> The main reason the simple approach you suggested (just link to a
> branch instead of a particular commit) isn't good is that it doesn't
> guarantee you always get the same version every time. If the
> supermodule links to submodule branch "foo" and makes supermodule
> commit 23abc918c, and someone later pushes to submodule branch "foo",
> then checking out commit 23abc918c in the supermodule would get the
> very latest submodule "foo", not the one you had when 23abc918c was
> created. Thus all sorts of bad things could happen.
It seems like this could be handled by changing the way a commit is
tracked such that it also includes the commit hash of the submodules.
So for example, instead of refs/heads/master just being just a single
commit hash, it would be a list:
[refs/heads/master]
1033bb1ed64d1dbac9f93360e69402195386d145
libfoo = a13dcb7f26a160d85038385b3024b700dec208d9
libbar = 123123123dcb7f26a160d85038385b3024b700de
If I commit a change to libfoo, it updates libfoo's commit hash to the latest.
If I do git pull on the supermodule, it recursively does git pull on
all submodules and then updates refs/heads/master (or whatever branch
you happen to be on) with the new commit hashes of the submodules.
If you checkout supermodule commit 1033bb1, it would look at the
supermodule's refs/heads/master for 1033bb and see that libfoo was at
a13dcb and libbar was at 123123 and it would then check out those
commits, respectively.
If you branch the supermodule, it recursively branches the submodules
with the same name, but using a namespace. Maybe super/<branch>
similar to how origin/branch is use for remote branches.
If you push the supermodule, it would also recursively push the
submodules using the URL specified when it was cloned (i.e. the one
specified in the .gitsubmodules file).
What I'm trying to do is use git to manage multiple, large
repositories that share a lot of code. I want to make things more
sparse so independent pieces can be used standalone or included as
submodules in other, larger projects.
prev parent reply other threads:[~2008-05-19 4:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-16 4:16 Why do git submodules require manual checkouts and commits? skillzero
2008-05-16 10:17 ` Johannes Schindelin
2008-05-16 13:43 ` Avery Pennarun
2008-05-16 13:58 ` Johannes Schindelin
2008-05-16 14:12 ` Avery Pennarun
2008-05-16 14:24 ` Johannes Schindelin
2008-05-16 14:44 ` Avery Pennarun
2008-05-16 14:58 ` Lars Hjemli
2008-05-19 4:38 ` skillzero [this message]
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2729632a0805182138s3e268cdbxd0d7c42bbcf01f84@mail.gmail.com \
--to=skillzero@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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 NNTP newsgroup(s).