git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: A Large Angry SCM <gitzilla@gmail.com>
To: Martin Waitz <tali@admingilde.org>
Cc: Shawn Pearce <spearce@spearce.org>,
	Daniel Barkalow <barkalow@iabervon.org>,
	git@vger.kernel.org
Subject: Re: Notes on Using Git with Subprojects
Date: Thu, 28 Sep 2006 13:30:39 -0700	[thread overview]
Message-ID: <451C30EF.8050305@gmail.com> (raw)
In-Reply-To: <20060928073706.GE8056@admingilde.org>

Martin Waitz wrote:
> On Wed, Sep 27, 2006 at 09:58:43AM -0700, A Large Angry SCM wrote:
>> This means that modules are not separate, stand alone projects but, 
>> rather, just a sub part of your bigger project. Very useful and 
>> applicable in some situations but other situations want/need separate, 
>> stand alone subprojects.
> 
> you can do everything with the submodule which would be possible with
> a normal GIT repository.  And you can always clone it into an directory
> which is not controlled by a parent project.
> 
> I really think that this is an very important property of a submodule.

I must be missing something.

I just read you original message in the (sub)thread again and you said:

	 * the .git/refs/heads directory of the submodule gets stored in
	   .gitmodule/<modulename> inside the parent project

If the submodule refs in the parent are a _copy_, then work performed in 
the submodule outside of the parent will be lost when the parent is in 
control of the submodule again.

If the submodule refs in the parent are the actual submodule refs then 
the submodule is not independent of the parent.

If the submodule refs in the parent are a symlink to the refs in the 
submodule, then the parent has no control over which version of the 
submodule it gets on the next checkout since the submodule can update 
the ref.

[...]
> One use-case which may be important here:
> 
> The submodule has two different branches which got forked and are not
> intended to be merged again.  At some point in time the parent project
> wants to switch from one branch of the submodule to another branch.
> If a user still has modifications in the old branch and wants to
> update the parent project then it is important to know if the local
> modifications and those coming from the parent have to be merged or
> should stay in different branches.
> If the parent is switching branches there should only be some warning
> if the user still has modifications in the old branch, giving him the
> chance to port the modifications to the other branch.

Again, this is leading me to believe that the submodule is not 
independent of the parent.

  reply	other threads:[~2006-09-28 20: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
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 [this message]
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=451C30EF.8050305@gmail.com \
    --to=gitzilla@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    --cc=tali@admingilde.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).