{"thread":{"id":"2449","subject":"Something looks like CVS modules","startedAt":"2005-11-11T07:13:26Z","lastAt":"2005-11-11T22:40:07Z","messageCount":9,"participants":["Alexander Litvinov","Junio C Hamano","Petr Baudis","Sven Verdoolaege","Josef Weidendorfer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11558","messageId":"200511111313.27273.lan@ac-sw.com","threadId":"2449","inReplyTo":null,"subject":"Something looks like CVS modules","fromName":"Alexander Litvinov","fromEmail":"lan@ac-sw.com","sentAt":"2005-11-11T07:13:26Z","receivedAt":"2005-11-11T07:13:26Z","isPatch":false,"sender":{"key":"lan@ac-sw.com","avatar":null},"body":"Does anybody can guide me how to replace CVS modules in the git enviroment ?\n\nCurrently we have few (~5) projects that can be used by others. At cvs world \nwe have modules and everything works fine. There are external links in the \nsvn word - almost the same except tags and branches.\n\nWhat can I do to make similar functionality with git ?\n"},{"id":"11564","messageId":"7vfyq3sj6z.fsf@assigned-by-dhcp.cox.net","threadId":"2449","inReplyTo":"200511111313.27273.lan@ac-sw.com","subject":"Re: Something looks like CVS modules","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-11T08:05:40Z","receivedAt":"2005-11-11T08:05:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexander Litvinov writes:\n\n> Does anybody can guide me how to replace CVS modules in the git enviroment ?\n\nSorry, no such thing as far as I can tell.\n\nAnd no, there is no plan to add such a thing before 1.0 at the\ncore level, sorry. Porcelains are separate story, though.\n"},{"id":"11570","messageId":"20051111102857.GM30496@pasky.or.cz","threadId":"2449","inReplyTo":"200511111313.27273.lan@ac-sw.com","subject":"Re: Something looks like CVS modules","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-11T10:28:57Z","receivedAt":"2005-11-11T10:28:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 11, 2005 at 08:13:26AM CET, I got a letter\nwhere Alexander Litvinov said that...\n> Does anybody can guide me how to replace CVS modules in the git enviroment ?\n> \n> Currently we have few (~5) projects that can be used by others. At cvs world \n> we have modules and everything works fine. There are external links in the \n> svn word - almost the same except tags and branches.\n> \n> What can I do to make similar functionality with git ?\n\nWell, what exactly is the problem with just having multiple\nrepositories?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11572","messageId":"200511111642.25908.lan@ac-sw.com","threadId":"2449","inReplyTo":"20051111102857.GM30496@pasky.or.cz","subject":"Re: Something looks like CVS modules","fromName":"Alexander Litvinov","fromEmail":"lan@ac-sw.com","sentAt":"2005-11-11T10:42:25Z","receivedAt":"2005-11-11T10:42:25Z","isPatch":false,"sender":{"key":"lan@ac-sw.com","avatar":null},"body":"On Friday 11 November 2005 16:28, Petr Baudis wrote:\n> Well, what exactly is the problem with just having multiple\n> repositories?\n\n1. The problem with checkout - single checkout should checkout all needed \nmodules to build project. Update should also update all modules. The same \nwith commit.\n2. Tags should be done on all modules. All modules should be able to be in the \nsame branch.\n\nAnd in the same time one module should be able to exists in two or more \nprojects !\n"},{"id":"11574","messageId":"20051111105820.GN30496@pasky.or.cz","threadId":"2449","inReplyTo":"200511111642.25908.lan@ac-sw.com","subject":"Re: Something looks like CVS modules","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-11T10:58:20Z","receivedAt":"2005-11-11T10:58:20Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 11, 2005 at 11:42:25AM CET, I got a letter\nwhere Alexander Litvinov said that...\n> On Friday 11 November 2005 16:28, Petr Baudis wrote:\n> > Well, what exactly is the problem with just having multiple\n> > repositories?\n> \n> 1. The problem with checkout - single checkout should checkout all needed \n> modules to build project. Update should also update all modules. The same \n> with commit.\n> 2. Tags should be done on all modules. All modules should be able to be in the \n> same branch.\n\nThen just have only a bunch of directories in your project root, and\nthat shall be your modules. :-)\n\n(CVS modules don't work like that either, do they?)\n\n> And in the same time one module should be able to exists in two or more \n> projects !\n\nBut this is troublesome, and doesn't fit into GIT's model at all. Do you\nhave any concrete example of a scenario where something like this would\nbe useful?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11576","messageId":"20051111111058.GQ8383MdfPADPa@greensroom.kotnet.org","threadId":"2449","inReplyTo":"20051111105820.GN30496@pasky.or.cz","subject":"Re: Something looks like CVS modules","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-11-11T11:10:58Z","receivedAt":"2005-11-11T11:10:58Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Fri, Nov 11, 2005 at 11:58:20AM +0100, Petr Baudis wrote:\n> Dear diary, on Fri, Nov 11, 2005 at 11:42:25AM CET, I got a letter\n> where Alexander Litvinov said that...\n> > And in the same time one module should be able to exists in two or more \n> > projects !\n> \n> But this is troublesome, and doesn't fit into GIT's model at all. Do you\n> have any concrete example of a scenario where something like this would\n> be useful?\n\nA .bib file shared by several publications.\n\nskimo\n"},{"id":"11577","messageId":"200511111713.58018.lan@ac-sw.com","threadId":"2449","inReplyTo":"20051111105820.GN30496@pasky.or.cz","subject":"Re: Something looks like CVS modules","fromName":"Alexander Litvinov","fromEmail":"lan@ac-sw.com","sentAt":"2005-11-11T11:13:57Z","receivedAt":"2005-11-11T11:13:57Z","isPatch":false,"sender":{"key":"lan@ac-sw.com","avatar":null},"body":"On Friday 11 November 2005 16:58, Petr Baudis wrote:\n> > 1. The problem with checkout - single checkout should checkout all needed\n> > modules to build project. Update should also update all modules. The same\n> > with commit.\n> > 2. Tags should be done on all modules. All modules should be able to be\n> > in the same branch.\n>\n> > And in the same time one module should be able to exists in two or more\n> > projects !\n>\n> Then just have only a bunch of directories in your project root, and\n> that shall be your modules. :-)\n>\n> (CVS modules don't work like that either, do they?)\n\nAs far as CVS tracks tags/branches separatly for each file, tags abd branches \nwork well for modules.\n\nBunch of directories is almost what I want except tags/branches/history. CVS \ndoes not care if two directories have separate root/repos. All it wants -is a \nproperly CVS dir.\n\n> But this is troublesome, and doesn't fit into GIT's model at all. Do you\n> have any concrete example of a scenario where something like this would\n> be useful?\n\nFor eaxmle: I have java lib A. I setup project B in this way:\nB/src/\nB/A/src\n\nHave another project C:\nC/src/\nC/A/src\n\nBoth of them share the same code from library's module. I can tag them, edit, \ncommit: do all work I usualy do. If I change something in B/A/src this will \nbe updated into C/A/src.\n\nThis is what I dreaming about :-)\n"},{"id":"11628","messageId":"20051111212953.GX30496@pasky.or.cz","threadId":"2449","inReplyTo":"200511111713.58018.lan@ac-sw.com","subject":"Re: Something looks like CVS modules","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-11T21:29:53Z","receivedAt":"2005-11-11T21:29:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 11, 2005 at 12:13:57PM CET, I got a letter\nwhere Alexander Litvinov said that...\n> On Friday 11 November 2005 16:58, Petr Baudis wrote:\n> > But this is troublesome, and doesn't fit into GIT's model at all. Do you\n> > have any concrete example of a scenario where something like this would\n> > be useful?\n> \n> For eaxmle: I have java lib A. I setup project B in this way:\n> B/src/\n> B/A/src\n> \n> Have another project C:\n> C/src/\n> C/A/src\n> \n> Both of them share the same code from library's module. I can tag them, edit, \n> commit: do all work I usualy do. If I change something in B/A/src this will \n> be updated into C/A/src.\n\nAha. So it isn't so much about modules, but more about nested checkouts,\ndescribed in Cogito's TODO as:\n\n* Subprojects\n\tSupport a GIT project inside a GIT project:\n\n\t\tx/.git\n\t\tx/foo/bar/.git\n\t\tx/foo/bar/baz/.git\n\t\tx/quux/zot/.git\n\n\tThat means cg-update working recursively and cg-add'n'stuff\n\tchecking if there isn't another .git along the path of its\n\targument.\n\n\tNeeds more thought, especially wrt. fetching and merging\n\trecursive semantics.\n\nYes, that would be nice - it is something that you get kind of for-free\nin CVS given its internal architecture, but needs specially crafted\nsupport in the GIT environment. But when thinking about it (and we\ndiscussed it with Jonas during one night bike ride through Copenhagen\nsome time ago ;), most of the problems with fetching and merging\nsemantics turn out to be actually largely artificial, and just doing\nthe intuitively right thing should be ok.\n\nPatches welcome. Otherwise, I will get to it, but not very fast. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11632","messageId":"200511112340.07794.Josef.Weidendorfer@gmx.de","threadId":"2449","inReplyTo":"20051111212953.GX30496@pasky.or.cz","subject":"Re: Something looks like CVS modules","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-11T22:40:07Z","receivedAt":"2005-11-11T22:40:07Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 11 November 2005 22:29, Petr Baudis wrote:\n> Dear diary, on Fri, Nov 11, 2005 at 12:13:57PM CET, I got a letter\n> where Alexander Litvinov said that...\n>\n> Aha. So it isn't so much about modules, but more about nested checkouts,\n> described in Cogito's TODO as:\n> \n> * Subprojects\n> ...\n\nInteresting. So these would be multiple git repositories, which are\nmore or less loosely coupled via same head and tag names?\n\nInstead of putting multiple git repositories in subdirectories,\nthese possibly could be combined into one .git/ with different index\nfiles, and simultaneously checked out files. This way, the\npartitioning of files does not have to follow directory boundaries\n(similar to the \"todo\" branch of git itself).\n\nWe would need a configuration for the partitioning.\nE.g. a .git/projects\n\n gitk: gitk\n todo: TODO TODO-docu\n docu: Documentation/*\n git: *\n\n(perhaps with path remapping between checkout files and paths in the\ngit tree objects of every subproject, to be flexible)\n\nYou would have multiple indexes: .git/index.gitk, .git/index.todo...\n.git/HEAD would have to hold multiple references for the currently\nchecked out subprojects:\n\n gitk: refs/gitk/heads/master\n git: refs/git/heads/master\n\nOn commiting, the subproject partitions are checked seperatly for\nchanges, and commits objects are done for each subproject.\nFetching/merging is done on each subproject of its own.\n\nYou probably want to have multi-head tags covering all subprojects.\n\nAnd for a more tight coupling of subprojects, you probably even want\nto have multihead commits every time a commit is done in one subproject,\nwhich leads to branches tracking the versioning of all subprojects,\ni.e. multihead heads ;-)\nI think that even subprojects of subprojects fall out naturally.\n\nI am quite sure this can be done in a fully compatible way to Git-1:\nwith Git-1, you have only one subproject, the empty one.\nIt should be possible to combine multiple Git-1 repositories to a\nrepository with multiple subprojects, where each subproject was its\nown project with Git-1.\n\nJosef\n"}]}