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 ?
Junio C HamanoRe: Something looks like CVS modules
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.
Petr BaudisRe: Something looks like CVS modules
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
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 !
Petr BaudisRe: Something looks like CVS modules
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
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
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 :-)
Petr BaudisRe: Something looks like CVS modules
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
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