Re: Something looks like CVS modules

Dear diary, on Fri, Nov 11, 2005 at 12:13:57PM CET, I got a letter
where Alexander Litvinov [off-list ref] said that...

On Friday 11 November 2005 16:58, Petr Baudis wrote:

quoted

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.