Something looks like CVS modules

Something looks like CVS modules

[Alexander Litvinov]

Does anybody can guide me how to replace CVS modules in the git enviroment ?

Currently we have few (~5) projects that can be used by others. At cvs world 
we have modules and everything works fine. There are external links in the 
svn word - almost the same except tags and branches.

What can I do to make similar functionality with git ?

Re: Something looks like CVS modules

[Junio C Hamano]

Alexander Litvinov <lan@ac-sw.com> writes:

> Does anybody can guide me how to replace CVS modules in the git enviroment ?

Sorry, no such thing as far as I can tell.

And no, there is no plan to add such a thing before 1.0 at the
core level, sorry.  Porcelains are separate story, though.

Re: Something looks like CVS modules

[Petr Baudis]

Dear diary, on Fri, Nov 11, 2005 at 08:13:26AM CET, I got a letter
where Alexander Litvinov <lan@ac-sw.com> said that...
> Does anybody can guide me how to replace CVS modules in the git enviroment ?
> 
> Currently we have few (~5) projects that can be used by others. At cvs world 
> we have modules and everything works fine. There are external links in the 
> svn word - almost the same except tags and branches.
> 
> What can I do to make similar functionality with git ?

Well, what exactly is the problem with just having multiple
repositories?

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

Re: Something looks like CVS modules

[Alexander Litvinov]

On Friday 11 November 2005 16:28, Petr Baudis wrote:
> Well, what exactly is the problem with just having multiple
> repositories?

1. The problem with checkout - single checkout should checkout all needed 
modules to build project. Update should also update all modules. The same 
with commit.
2. Tags should be done on all modules. All modules should be able to be in the 
same branch.

And in the same time one module should be able to exists in two or more 
projects !

Re: Something looks like CVS modules

[Petr Baudis]

Dear diary, on Fri, Nov 11, 2005 at 11:42:25AM CET, I got a letter
where Alexander Litvinov <lan@ac-sw.com> said that...
> On Friday 11 November 2005 16:28, Petr Baudis wrote:
> > Well, what exactly is the problem with just having multiple
> > repositories?
> 
> 1. The problem with checkout - single checkout should checkout all needed 
> modules to build project. Update should also update all modules. The same 
> with commit.
> 2. Tags should be done on all modules. All modules should be able to be in the 
> same branch.

Then just have only a bunch of directories in your project root, and
that shall be your modules. :-)

(CVS modules don't work like that either, do they?)

> And in the same time one module should be able to exists in two or more 
> projects !

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?

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

Re: Something looks like CVS modules

[Sven Verdoolaege]

On Fri, Nov 11, 2005 at 11:58:20AM +0100, Petr Baudis wrote:
> Dear diary, on Fri, Nov 11, 2005 at 11:42:25AM CET, I got a letter
> where Alexander Litvinov <lan@ac-sw.com> said that...
> > And in the same time one module should be able to exists in two or more 
> > projects !
> 
> 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?

A .bib file shared by several publications.

skimo

Re: Something looks like CVS modules

[Alexander Litvinov]

On Friday 11 November 2005 16:58, Petr Baudis wrote:
> > 1. The problem with checkout - single checkout should checkout all needed
> > modules to build project. Update should also update all modules. The same
> > with commit.
> > 2. Tags should be done on all modules. All modules should be able to be
> > in the same branch.
>
> > And in the same time one module should be able to exists in two or more
> > projects !
>
> Then just have only a bunch of directories in your project root, and
> that shall be your modules. :-)
>
> (CVS modules don't work like that either, do they?)

As far as CVS tracks tags/branches separatly for each file, tags abd branches 
work well for modules.

Bunch of directories is almost what I want except tags/branches/history. CVS 
does not care if two directories have separate root/repos. All it wants -is a 
properly CVS dir.

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

This is what I dreaming about :-)

Re: Something looks like CVS modules

[Petr Baudis]

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.

Re: Something looks like CVS modules

[Josef Weidendorfer]

On Friday 11 November 2005 22:29, Petr Baudis wrote:
> 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...
>
> Aha. So it isn't so much about modules, but more about nested checkouts,
> described in Cogito's TODO as:
> 
> * Subprojects
> ...

Interesting. So these would be multiple git repositories, which are
more or less loosely coupled via same head and tag names?

Instead of putting multiple git repositories in subdirectories,
these possibly could be combined into one .git/ with different index
files, and simultaneously checked out files. This way, the
partitioning of files does not have to follow directory boundaries
(similar to the "todo" branch of git itself).

We would need a configuration for the partitioning.
E.g. a .git/projects

 gitk: gitk
 todo: TODO TODO-docu
 docu: Documentation/*
 git: *

(perhaps with path remapping between checkout files and paths in the
git tree objects of every subproject, to be flexible)

You would have multiple indexes: .git/index.gitk, .git/index.todo...
.git/HEAD would have to hold multiple references for the currently
checked out subprojects:

 gitk: refs/gitk/heads/master
 git: refs/git/heads/master

On commiting, the subproject partitions are checked seperatly for
changes, and commits objects are done for each subproject.
Fetching/merging is done on each subproject of its own.

You probably want to have multi-head tags covering all subprojects.

And for a more tight coupling of subprojects, you probably even want
to have multihead commits every time a commit is done in one subproject,
which leads to branches tracking the versioning of all subprojects,
i.e. multihead heads ;-)
I think that even subprojects of subprojects fall out naturally.

I am quite sure this can be done in a fully compatible way to Git-1:
with Git-1, you have only one subproject, the empty one.
It should be possible to combine multiple Git-1 repositories to a
repository with multiple subprojects, where each subproject was its
own project with Git-1.

Josef