All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Waitz <tali@admingilde.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: A Large Angry SCM <gitzilla@gmail.com>,
	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 14:46:04 +0200	[thread overview]
Message-ID: <20060927124604.GD8056@admingilde.org> (raw)
In-Reply-To: <Pine.LNX.4.63.0609271358100.14200@wbgn013.biozentrum.uni-wuerzburg.de>

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

hoi :)

On Wed, Sep 27, 2006 at 02:01:11PM +0200, Johannes Schindelin wrote:
> On Wed, 27 Sep 2006, Martin Waitz wrote:
> > On Wed, Sep 27, 2006 at 11:55:22AM +0200, Johannes Schindelin wrote:
> > > > 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
> > > 
> > > Taking this a step further, you could make subproject/.git/refs/heads a 
> > > symbolic link to .git/refs/heads/subproject, with the benefit that fsck 
> > > Just Works.
> > 
> > in fact it is done this way (more or less).
> 
> With the difference, that if you store the refs outside of 
> <root>/.git/refs, you have to take extra care that prune does not delete 
> the corresponding objects.

that's why there is .git/refs/module/modulname -> .gitmodule/modulename.

> > You can accumulate as many changes in different subprojects until you
> > get to a state that is worth committing in the parent project.
> > All these changes are then seen as one atomic change to the whole
> > project.
> 
> AFAICT this is not the idea of subprojects-in-git. If you have to track 
> the subprojects in the root project manually anyway, you don't need _any_ 
> additional tool (you _can_ track files in a subdirectory containing a .git 
> subdirectory).

But then you loose the fine grained commits of your subprojects.
You only store the tree of the subproject when committing to the parent,
not the entire history.

I think having the "commit subproject changes to parent" step as a
manual action makes sense in the same way as you have to trigger a
commit to a repository by hand, too. You are not storing every little
change to your filesystem in the database.

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2006-09-27 12:46 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
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 [this message]
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=20060927124604.GD8056@admingilde.org \
    --to=tali@admingilde.org \
    --cc=Johannes.Schindelin@gmx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.