From: Martin Waitz <tali@admingilde.org>
To: A Large Angry SCM <gitzilla@gmail.com>
Cc: Shawn Pearce <spearce@spearce.org>,
Daniel Barkalow <barkalow@iabervon.org>,
git@vger.kernel.org
Subject: Re: Notes on Using Git with Subprojects
Date: Wed, 27 Sep 2006 10:06:52 +0200 [thread overview]
Message-ID: <20060927080652.GA8056@admingilde.org> (raw)
In-Reply-To: <4519AACD.7020508@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]
hoi :)
On Tue, Sep 26, 2006 at 03:33:49PM -0700, A Large Angry SCM wrote:
> So, for each subproject of a parent project, you want to record branch,
> version (commit ID), and directory location. Not quite as easy to do in
> a makefile but do-able.
I've been playing with this kind of subprojects a little bit.
My current approach is like this:
* create a .gitmodules file which lists all the directories
which contain a submodule.
* the .git/refs/heads directory of the submodule gets stored in
.gitmodule/<modulename> inside the parent project
* both things above should be tracked in the parent project.
This way you always store the current state of each submodule
in each commit of the parent project. And you don't have to
create a new parent commit for each change. You can commit
to the parent project when you think that all your modules are
in a good state.
* When checking out a project, all submodules listen in .gitmodules
get checked out, too.
* If there is a merge conflict in the module list or its refs/heads,
this is handled specially, e.g. by triggering a new merge inside
the submodule.
* The object directory is shared between the parent and all modules.
To make fsck-objects happy, the parent gets a refs/module link
pointing to .gitmodule/ and all submodules get a refs/parent
link pointing to the refs directory of the parent.
The concept is similiar to the gitlink objects which have been floating
around, but it is easier to prototype as no new git object type has to
be created. If it works well we can later move the information stored
in .gitmodule* into an object type of its own.
By storing the complete refs/heads directory for each submodule instead
of only one head, it is possible to track multiple branches of a
subproject. I'm don't know yet how this works out in praktice but I
think that it can be nice to be able to atomically commit to several
branches of one submodule (perhaps one branch per customer, per
hardware platform, whatever).
So, what have I done up to now? Not much. I created a little
script to set up a submodule as described above:
http://git.admingilde.org/?p=tali/git.git;a=blob;f=git-init-module.sh;h=0108873fd3aa8a42035039b19e8555513c075fca;hb=module
Next steps would be to modify clone and checkout to actually be able
to work in such a setup. If this works then merging of subprojects
has to be done (the most complex part I guess).
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-09-27 8:07 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-26 17:40 Notes on Using Git with Subprojects A Large Angry SCM
2006-09-26 20:25 ` Johannes Schindelin
2006-09-26 22:01 ` A Large Angry SCM
2006-09-26 22:13 ` Johannes Schindelin
2006-09-26 22:45 ` A Large Angry SCM
2006-09-26 21:23 ` Daniel Barkalow
2006-09-26 21:30 ` Shawn Pearce
2006-09-26 22:33 ` A Large Angry SCM
2006-09-27 8:06 ` Martin Waitz [this message]
2006-09-27 9:55 ` Johannes Schindelin
2006-09-27 11:38 ` Martin Waitz
2006-09-27 12:01 ` Johannes Schindelin
2006-09-27 12:44 ` Sven Verdoolaege
2006-09-27 21:05 ` Junio C Hamano
2006-09-28 15:02 ` Michael S. Tsirkin
2006-09-28 20:16 ` Jeff King
2006-09-27 12:46 ` Martin Waitz
2006-09-27 13:13 ` Johannes Schindelin
2006-09-27 17:13 ` A Large Angry SCM
2006-09-27 23:14 ` Johannes Schindelin
2006-09-27 23:36 ` Shawn Pearce
2006-09-27 23:55 ` Rogan Dawes
2006-09-28 0:36 ` Shawn Pearce
2006-09-28 5:02 ` A Large Angry SCM
2006-09-28 4:48 ` A Large Angry SCM
2006-09-27 16:58 ` A Large Angry SCM
2006-09-27 17:33 ` Jeff King
2006-09-28 3:47 ` A Large Angry SCM
2006-09-28 3:52 ` Jeff King
2006-09-28 3:58 ` Shawn Pearce
2006-09-28 4:00 ` Jeff King
2006-09-28 4:09 ` Shawn Pearce
2006-09-28 3:52 ` Shawn Pearce
2006-09-28 15:39 ` Johannes Schindelin
2006-09-28 7:37 ` Martin Waitz
2006-09-28 20:30 ` A Large Angry SCM
2006-09-29 7:04 ` Martin Waitz
2006-09-26 22:07 ` A Large Angry SCM
2006-10-01 5:19 ` A Large Angry SCM
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=20060927080652.GA8056@admingilde.org \
--to=tali@admingilde.org \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitzilla@gmail.com \
--cc=spearce@spearce.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).