git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Pearce <spearce@spearce.org>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: A Large Angry SCM <gitzilla@gmail.com>, git@vger.kernel.org
Subject: Re: Notes on Using Git with Subprojects
Date: Tue, 26 Sep 2006 17:30:03 -0400	[thread overview]
Message-ID: <20060926213003.GA8177@spearce.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0609261629160.9789@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 26 Sep 2006, A Large Angry SCM wrote:
> 
> > Git, unfortunately, does not make it easy. What is wanted is to put all
> > of the subprojects in one repository and be able to checkout the various
> > parts from a local copy of the repository. The problem is, with Git, a
> > repository can have at most one working directory associated with it at
> > a time. This is because Git stores a lot of information about the
> > contents of the working directory in the repository. In fact, the usual
> > situation is that the repository, itself, is in the working directory.
> 
> There are a bunch of use cases which people see as subprojects, with 
> slightly different desires. For example, I personally don't think there's 
> any point to subprojects if a commit of the parent project doesn't specify 
> the embedded commits of each subproject (so, for example, you can use 
> bisect on the parent project to figure out which act of updating a 
> subproject broke the resulting system). AFAICT, your design doesn't handle 
> that, but uses the most recently fetched versions of all subprojects, with 
> the revision control of the parent only handling revisions in the 
> arrangement and membership of subprojects in the parent.

I agree entirely.

I have about 30 "subprojects" tacked into one large Git repository
for this exact reason.  In at least 5 of these cases they shouldn't
be sharing a Git repository as by all rights they are different
projects.

What I'm doing is sort of like tacking both the Linux kernel and
glibc into the same Git repository because you might need to change
and bisect over updates to the system call layer.  Insane, yes.
Probably shouldn't be done; but right now that interface layer
between several subprojects is still in flux and it makes it rather
easy to keep everything in sync.

Its annoying to perform commits to the "root project" every time the
subproject changes.  And it brings some complexity when you want to
talk about merging that root project.  But if its automated as part
of "git commit" and "git merge" (either directly in those tools or
by hooks users can install) then its probbaly a non issue.

-- 
Shawn.

  reply	other threads:[~2006-09-26 21:30 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 [this message]
2006-09-26 22:33     ` A Large Angry SCM
2006-09-27  8:06       ` Martin Waitz
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=20060926213003.GA8177@spearce.org \
    --to=spearce@spearce.org \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitzilla@gmail.com \
    /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).