{"thread":{"id":"13145","subject":"Best way to re-do a CVS repository with git?","startedAt":"2008-04-17T02:37:38Z","lastAt":"2008-04-19T22:49:46Z","messageCount":4,"participants":["skillzero@gmail.com","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74612","messageId":"2729632a0804161937w168aba8ahee742e182e50b4e7@mail.gmail.com","threadId":"13145","inReplyTo":null,"subject":"Best way to re-do a CVS repository with git?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2008-04-17T02:37:38Z","receivedAt":"2008-04-17T02:37:38Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"I have a large CVS repository (1.5 GB without its history) that I'd\nlike to convert to git, but I'm not sure about the right way to set it\nup. If I need to change the way I'm thinking about source code\nmanagement, that's fine too, but here's what I have today in a single\nCVS repository:\n\nMyProject\n Apps # Only apps people use this.\n Common # Everyone uses this.\n Firmware # Only firmware people use this.\n External/ProjectA # Only app people use this.\n External/ProjectB # Everyone uses this.\n External/ProjectC # Only firmware people use this. This is 1 GB\nof code by itself.\n\nI manage this today with CVS modules, one for apps people and one for\nfirmware people (and another CVS module with everything for people\nlike me that work on both).\n\nI initially thought I'd create separate git repositories for each\npiece, but I'm not sure how that would work when it comes to tagging\nan entire release (i.e. a tag that spans multiple repositories). Or\nhow it would handle a git repository within a directory managed by\nanother git repository.\n\nWhat's the best way to set up something like this with git?\n"},{"id":"74746","messageId":"m3wsmuqmmp.fsf@localhost.localdomain","threadId":"13145","inReplyTo":"2729632a0804161937w168aba8ahee742e182e50b4e7@mail.gmail.com","subject":"Re: Best way to re-do a CVS repository with git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-19T08:23:25Z","receivedAt":"2008-04-19T08:23:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I think the subject would better read:\n\"What is best way to represent multimodule CVS repository in Git?\"\n\nskillzero@gmail.com writes:\n\n> I have a large CVS repository (1.5 GB without its history) that I'd\n> like to convert to git, but I'm not sure about the right way to set it\n> up. If I need to change the way I'm thinking about source code\n> management, that's fine too, but here's what I have today in a single\n> CVS repository:\n> \n> MyProject\n> Apps # Only apps people use this.\n> Common # Everyone uses this.\n> Firmware # Only firmware people use this.\n> External/ProjectA # Only app people use this.\n> External/ProjectB # Everyone uses this.\n> External/ProjectC # Only firmware people use this. This is 1 GB\n> of code by itself.\n> \n> I manage this today with CVS modules, one for apps people and one for\n> firmware people (and another CVS module with everything for people\n> like me that work on both).\n> \n> I initially thought I'd create separate git repositories for each\n> piece, but I'm not sure how that would work when it comes to tagging\n> an entire release (i.e. a tag that spans multiple repositories). Or\n> how it would handle a git repository within a directory managed by\n> another git repository.\n> \n> What's the best way to set up something like this with git?\n\nI think that such setup would be best managed by creating Git\nrepository for each piece, and \"integration\" repositories, one for\napps people, and one for firmware people, using submodule support in\nGit.\n\nTagging entire release would be tagging in \"integration\" repository,\nthe one using submodules.\n\nSee also:\n * http://git.or.cz/gitwiki/SubmoduleSupport\n * http://git.or.cz/gitwiki/GitSubmoduleTutorial\n * http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html\n aka git-submodule(1)\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"74766","messageId":"2729632a0804191247t4458067etfc1627a533a84376@mail.gmail.com","threadId":"13145","inReplyTo":"m3wsmuqmmp.fsf@localhost.localdomain","subject":"Re: Best way to re-do a CVS repository with git?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2008-04-19T19:47:31Z","receivedAt":"2008-04-19T19:47:31Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"On Sat, Apr 19, 2008 at 1:23 AM, Jakub Narebski wrote:\n> I think that such setup would be best managed by creating Git\n> repository for each piece, and \"integration\" repositories, one for\n> apps people, and one for firmware people, using submodule support in\n> Git.\n\n> Tagging entire release would be tagging in \"integration\" repository,\n> the one using submodules.\n\nThanks for the info. git submodules seem like the right direction. But\nunless I'm misreading the tutorial, using submodules would require\neach user to know about and maintain every super module that might use\neach submodule. For example, if you had:\n\nmoduleA\n\tfileA.txt\nmoduleB\n\tfileB.txt\nmoduleC\n\tfileC.txt\n\nsuper1\n\tmoduleA\n\tmoduleC\n\nsuper2\n\tmoduleB\n\tmoduleC\n\nsuper3\n\tmoduleA\n\tmoduleC\n\nI commit a change in fileA.txt (in moduleA). I now have to commit\nmoduleA to super1 and then commit moduleA to super3. Otherwise, super1\nand super3 would still refer to the previous commit of moduleA. That's\na good amount of extra work (I can imagine there may being dozens of\nsuper projects referring to a certain submodule).\n\nBut there's a more serious problem in my case because not all users\nhave access to all repositories. For example, if I have access to\nsuper1, but not super3 (I may not even know super3 exists), I won't be\nable to update super3. Now super3 is in a weird state: it has moduleA\nas a submodule, but it refers to an older revision of moduleA.\nSomebody with access to super3 has to know that moduleA has changes\nthat haven't been included in super3 and manually pull them.\n\nOr am I just misunderstand how submodules work? It seems to me that\nthe super module could use a more abstract link: the super repository\nwould refer to a branch name (e.g. master). Then when I do a git pull\nfrom super1, it would see it contains moduleA on branch \"master\" and\nwould pull down the latest \"master\" branch from moduleA without ever\nhaving to commit moduleA to super1 or super3.\n\nThis is probably harder than it sounds, but it would seem to eliminate\nthe need to know anything about super modules (except initially when\nthe super repository is created). I just commit to moduleA and the\nnext time somebody pulls from super1 or super3, they get the change\nautomatically.\n"},{"id":"74777","messageId":"m3k5itqx2v.fsf@localhost.localdomain","threadId":"13145","inReplyTo":"2729632a0804191247t4458067etfc1627a533a84376@mail.gmail.com","subject":"Re: Best way to re-do a CVS repository with git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-19T22:49:46Z","receivedAt":"2008-04-19T22:49:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"skillzero@gmail.com writes:\n\n> On Sat, Apr 19, 2008 at 1:23 AM, Jakub Narebski wrote:\n> > I think that such setup would be best managed by creating Git\n> > repository for each piece, and \"integration\" repositories, one for\n> > apps people, and one for firmware people, using submodule support in\n> > Git.\n> \n> > Tagging entire release would be tagging in \"integration\" repository,\n> > the one using submodules.\n> \n> Thanks for the info. git submodules seem like the right direction.\n[cut]\n\nI don't know if using submodules is a right solution: git submodules\nare for more or less loosely tied projects. It is a solution which is\nworth considering. It allows for example developing some experimental\nfeature in subproject, while superproject use stable, tested version\nof submodule.\n\nAnother solution is to merge subproject directly to superproject using\n'subtree' merge strategy, like currently gitk and git-gui is\nmaintained/managed in git.\n\nYet another would be to use something similar to Mercurial's fores, or\none of earlier submodule implementations, namely git repositories\ninside working directories in other git repositories.\n\n\nAnd perhaps you would have to roll your own scripts around git, so\nsingle commit would trigger commit in supermodule; that or write your\nown hook scripts to do that.\n\n\nUnfortunately it seems like nobody interested in your plight... and I\ncannot help mych beyound that what I've wrote...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}