git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Alexander Litvinov <lan@ac-sw.com>
Cc: git@vger.kernel.org
Subject: Re: Something looks like CVS modules
Date: Fri, 11 Nov 2005 22:29:53 +0100	[thread overview]
Message-ID: <20051111212953.GX30496@pasky.or.cz> (raw)
In-Reply-To: <200511111713.58018.lan@ac-sw.com>

Dear diary, on Fri, Nov 11, 2005 at 12:13:57PM CET, I got a letter
where Alexander Litvinov <lan@ac-sw.com> said that...
> On Friday 11 November 2005 16:58, Petr Baudis wrote:
> > But this is troublesome, and doesn't fit into GIT's model at all. Do you
> > have any concrete example of a scenario where something like this would
> > be useful?
> 
> For eaxmle: I have java lib A. I setup project B in this way:
> B/src/
> B/A/src
> 
> Have another project C:
> C/src/
> C/A/src
> 
> Both of them share the same code from library's module. I can tag them, edit, 
> commit: do all work I usualy do. If I change something in B/A/src this will 
> be updated into C/A/src.

Aha. So it isn't so much about modules, but more about nested checkouts,
described in Cogito's TODO as:

* Subprojects
	Support a GIT project inside a GIT project:

		x/.git
		x/foo/bar/.git
		x/foo/bar/baz/.git
		x/quux/zot/.git

	That means cg-update working recursively and cg-add'n'stuff
	checking if there isn't another .git along the path of its
	argument.

	Needs more thought, especially wrt. fetching and merging
	recursive semantics.

Yes, that would be nice - it is something that you get kind of for-free
in CVS given its internal architecture, but needs specially crafted
support in the GIT environment. But when thinking about it (and we
discussed it with Jonas during one night bike ride through Copenhagen
some time ago ;), most of the problems with fetching and merging
semantics turn out to be actually largely artificial, and just doing
the intuitively right thing should be ok.

Patches welcome. Otherwise, I will get to it, but not very fast. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

  reply	other threads:[~2005-11-11 21:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-11  7:13 Something looks like CVS modules Alexander Litvinov
2005-11-11  8:05 ` Junio C Hamano
2005-11-11 10:28 ` Petr Baudis
2005-11-11 10:42   ` Alexander Litvinov
2005-11-11 10:58     ` Petr Baudis
2005-11-11 11:10       ` Sven Verdoolaege
2005-11-11 11:13       ` Alexander Litvinov
2005-11-11 21:29         ` Petr Baudis [this message]
2005-11-11 22:40           ` Josef Weidendorfer

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=20051111212953.GX30496@pasky.or.cz \
    --to=pasky@suse.cz \
    --cc=git@vger.kernel.org \
    --cc=lan@ac-sw.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).