On Fri, May 16, 2008 at 6:43 AM, Avery Pennarun <apenwarr@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
