From: Finn Arne Gangstad <finnag@pvv.org>
To: git@vger.kernel.org
Subject: Partial checkouts / submodules
Date: Tue, 20 Nov 2007 16:59:22 +0100 [thread overview]
Message-ID: <20071120155922.GA6271@pvv.org> (raw)
My use case it this: We have some huge projects (let's call them
supermodules) that are the only products we really release. Any change
going into any of the submodules go in solely to modify the
superproject, the submodules are not released on their own.
We cannot keep the supermodule with all its submodules in one git
repository for two reasons: Size & sharing. A 6GB+ repository is too
big to handle gracefully, and there are multiple superprojects sharing
some of the submodules. Our supermodules typically contains 50-250
submodules. Usually it is sufficient to look at just a few of these
submodules at the same time.
I looked into the current git submodules to see if they support what I
think we need, but it seems like they do not really cut it (If I'm
wrong about this, please educate me).
What I want is this:
Somewhere the following modules all exist:
supermodule/
submodule1
submodule2
submodule3
...
submodule200
You pull the supermodule, and initialize random collection of
submodules, e.g. locally you have:
supermodule/
submodule13
submodule71
submodule102
Now I want this to behave as if it was a partial checkout of
"supermodule" - i.e. I want _all_ operations in any of the submodules
to act as if they happened in all the submodules (as if supermodule
was a single repository containing all the submodules directly).
If I do a change in submodule13, another change in submodule71 and yet
another change in submodule102, I want to be able to commit them all
as ONE commit (obviously it will be 4 commits, 1 in each submodule and
one in the supermodule, but anyone looking at this in the context of
this supermodule should see it as one commit).
If I pull supermodule, I get updates to supermodule, submodule13,
submodule71 and submodule102, but nothing else.
If I make a branch on submodule71, the branch is made in all submodules &
the supermodule.
With this setup it should be possible to handle supermodule as a
normal module with branches for each feature/topic/bugfix, and those
features being merged into other branches in a reasonable way. Does
something like this look doable?
- Finn Arne
next reply other threads:[~2007-11-20 16:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-20 15:59 Finn Arne Gangstad [this message]
2007-11-20 17:33 ` Partial checkouts / submodules Sven Verdoolaege
2007-11-20 18:19 ` Finn Arne Gangstad
2007-11-20 18:42 ` Sven Verdoolaege
2007-11-20 18:59 ` Daniel Barkalow
2007-11-20 19:22 ` Finn Arne Gangstad
2007-11-20 20:18 ` Daniel Barkalow
2007-11-21 0:04 ` Jakub Narebski
2007-11-20 18:03 ` Daniel Barkalow
2007-11-20 18:26 ` Steven Grimm
2007-11-20 18:36 ` Daniel Barkalow
2007-11-20 18:55 ` Sergei Organov
2007-11-20 19:15 ` Daniel Barkalow
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=20071120155922.GA6271@pvv.org \
--to=finnag@pvv.org \
--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