{"thread":{"id":"6031","subject":"[ANNOUNCE] repo.or.cz now supports \"project forks\"","startedAt":"2006-10-24T04:52:01Z","lastAt":"2006-10-24T17:39:43Z","messageCount":2,"participants":["Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29805","messageId":"20061024045201.GX20017@pasky.or.cz","threadId":"6031","inReplyTo":null,"subject":"[ANNOUNCE] repo.or.cz now supports \"project forks\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-24T04:52:01Z","receivedAt":"2006-10-24T04:52:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\n FYI, the http://repo.or.cz/ public Git hosting now supports project\nforking, which basically means that if you've done something cool to an\nexisting project and want to publish your work, you can create a \"fork\"\nof the project on repo.or.cz and it will group nicely together in gitweb\nand users will be hinted about the possibility to use --reference when\ncloning your changes; also, repo.or.cz disk space will be conserved\nthanks to the alternates mechanism. ;-)\n\n The other main goal aside gitweb grouping wasn't achieved yet though -\ngreatly reduced push times. Hey, pushing Git to a new repository takes\ninordinate amount of time (actually also mostly because all the objects are\nunpacked on the remote side, which is silly as well), I didn't try pushing\nLinux kernel to a fresh repository but it'll likely take ages. The idea\nwould be to make git-receive-pack take alternates into account when\nannouncing what commits does the server side have, but someone will need\nto code up a patch for that...\n\n It wasn't tested heavily, so please tell me about any warts you hit.\n\n Thanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> FYI, the http://repo.or.cz/ public Git hosting now supports project\n> forking, which basically means that if you've done something cool to an\n> existing project and want to publish your work, you can create a \"fork\"\n> of the project on repo.or.cz and it will group nicely together in gitweb\n> and users will be hinted about the possibility to use --reference when\n> cloning your changes; also, repo.or.cz disk space will be conserved\n> thanks to the alternates mechanism. ;-)\n> \n> The other main goal aside gitweb grouping wasn't achieved yet though -\n> greatly reduced push times. Hey, pushing Git to a new repository takes\n> inordinate amount of time (actually also mostly because all the objects are\n> unpacked on the remote side, which is silly as well), I didn't try pushing\n> Linux kernel to a fresh repository but it'll likely take ages. The idea\n> would be to make git-receive-pack take alternates into account when\n> announcing what commits does the server side have, but someone will need\n> to code up a patch for that...\n\n BTW, someone asked me why not stuff it in branches in the same\ndirectory, and it's a valid question. It's been my original plan (and I\nmight still implement it sometimes since it makes sense in some\nsituations) but after I formulated it at #git I realized that it's\nreally a no-go for the general case.\n\n The plan was to have \"personal mob-branches\", mob/$login/*. Anyone can\nmake any branch in the mob/$login namespace in any project. But I didn't\nfeel like implementing it for now, because:\n\n\t* git-clone / cg-clone -a would clone even the potential gazillion\n\t of mob/$login branches any weirdo can create\n\n\t* You get own heads namespace but own tags namespace would be\n\t I think more inconvenient since you tend to refere to tags\n\t much more often than to branches (if you even have one than\n\t one branch) and having to write mob/mynameisverylong/xyzzy-1.2.3.4\n\t is, er...\n\n\t* One of the big points of forks is that you can fork even\n\t mirrored projects. If you start to create branches in mirrored\n\t projects, you can get into very ugly problems when by a chance\n\t the mirrored project gets such a branch as well\n\n One sad consequence is that graphiclog does not include the forked\nprojects, OTOH perhaps its view would be way too cluttered if it did,\nand I want to optimize for a large number of forks. So it would be more\nsensible if someone (hint, hint) patched git-browser in a way so that\nforked projects include the \"forkee\"'s refs in the view as well, in\naddition to own refs. And perhaps a more general notion for this in the\nGit world would be interesting.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i