{"thread":{"id":"25177","subject":"Announce gitslave - manage a superproject with slave repositories","startedAt":"2010-09-21T01:39:01Z","lastAt":"2010-09-23T22:49:30Z","messageCount":3,"participants":["Seth Robertson","Jakub Narebski","Thomas Adam"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"151178","messageId":"201009210139.o8L1d1iY026728@no.baka.org","threadId":"25177","inReplyTo":null,"subject":"Announce gitslave - manage a superproject with slave repositories","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2010-09-21T01:39:01Z","receivedAt":"2010-09-21T01:39:01Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nI'd like to announce the first public version of gitslave.\n\ngitslave creates a group of related repositories all of which are\nconcurrently developed on and on which all git operations should\noperate, so when you branch, each repository in the project is\nbranched in turn.  Similarly when you commit, push, pull, merge,\ntag, checkout, status, log, etc; each git command will run on the\nsuperproject and all slave repositories in turn.  This sort of\nactivity may be very familiar to CVS users and to a lesser extent\nsubversion users where it was fairly normal to assemble a\nsuperproject in just this way.\n\ngit-submodules is the legacy solution for a similar sort of\nactivity, but went a different way.  With submodules you have a\nsemi-fixed subrepository which you are typically not doing active\ndevelopment on and which git commands performed on the\nsuperproject will not recurse down into the submodules. Another\noption is to stick everything in one giant repository, but that\ndoes not work well if some subsets are shared with other\nsuperprojects.\n\nThe gits wrapper around git combines (and occasionally\npost-processes for some special commands) the git output to make\neverything clearer, which is very useful when you have a few\ndozen slaves where looking at a concatenation of identical output\nfor each git command would lose the wheat in the chaff.\n\nHowever, gitslave is not perfect. You can have partial success\nand failure (which is advertised), programs like `gitk` will not\nshow the global systems' history only a specific repository's,\nand things can get a little squirrelly if different branches/tags\nhave different slave modules associated with them and you\ncheckout back and forth.  However, we have not had any\nsignificant problems in over two years of intensive work on a\nproject using this script.\n\nIf your development style or project lends itself to many\nindividual repositories, and those repositories are under your\ndirect control and all repositories should at identical\nbranch names at the same time, gitslave might just be for you.\n\nhttp://gitslave.sourceforge.net/\n\nCurrent release as of 2010-09-20: 1.0.0\nhttp://sourceforge.net/projects/gitslave/files/gitslave-1.0.0.tar.gz/download\n\n                                        -Seth Robertson\n"},{"id":"151256","messageId":"m3r5gmkbw0.fsf@localhost.localdomain","threadId":"25177","inReplyTo":"201009210139.o8L1d1iY026728@no.baka.org","subject":"Re: Announce gitslave - manage a superproject with slave repositories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-21T21:47:44Z","receivedAt":"2010-09-21T21:47:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Seth Robertson <in-gitvger@baka.org> writes:\n\n> I'd like to announce the first public version of gitslave.\n> \n> gitslave creates a group of related repositories all of which are\n> concurrently developed on and on which all git operations should\n> operate, so when you branch, each repository in the project is\n> branched in turn.  Similarly when you commit, push, pull, merge,\n> tag, checkout, status, log, etc; each git command will run on the\n> superproject and all slave repositories in turn.  This sort of\n> activity may be very familiar to CVS users and to a lesser extent\n> subversion users where it was fairly normal to assemble a\n> superproject in just this way.\n[...]\n\n> http://gitslave.sourceforge.net/\n> \n> Current release as of 2010-09-20: 1.0.0\n> http://sourceforge.net/projects/gitslave/files/gitslave-1.0.0.tar.gz/download\n\nCould you please add information about this project to\nInterfacesFrontendsAndTools page on Git Wiki:\n  https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n\nSomewhere in neighbourhood of 'repo' or 'git-subtree' could be good.\n\nThanks in advance.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"151411","messageId":"AANLkTimf2Oe-w-QG_XeyP1OJ1FnfW6ym_OjLuUeqKo=F@mail.gmail.com","threadId":"25177","inReplyTo":"201009210139.o8L1d1iY026728@no.baka.org","subject":"Re: Announce gitslave - manage a superproject with slave repositories","fromName":"Thomas Adam","fromEmail":"thomas@xteddy.org","sentAt":"2010-09-23T22:49:30Z","receivedAt":"2010-09-23T22:49:30Z","isPatch":false,"sender":{"key":"thomas@xteddy.org","avatar":"https://gravatar.com/avatar/e7256db4738e501e5d2e84f00bb0bd99503165729573848a03330301fc2adc4a?d=mp&s=160"},"body":"Hi --\n\nOn 21 September 2010 02:39, Seth Robertson <in-gitvger@baka.org> wrote:\n>\n> I'd like to announce the first public version of gitslave.\n\nI had a very quick cursive look at the perl.  Any reason why you're\nusing using the Git module shipped with GIt, and relying on your own\nuse of system() which is arguarbly bad?\n\n-- Thomas Adam\n"}]}