Re: Something looks like CVS modules

From: Petr Baudis <pasky@suse.cz>
Date: Nov 11, 2005, 21:29 UTC
Message-ID: <20051111212953.GX30496@pasky.or.cz>
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...

Show 16 quoted lines

> 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.