On Sat, Sep 4, 2010 at 2:52 AM, Artur Skawina <art.08.09@xxxxxxxxx> wrote: > Hmm, taking a few steps back, what is the expected usage of git-p2p? > Note it's a bit of a trick question; what i'm really asking is what _else_, > other than pulling/tracking Linus' kernel tree will/can be done with it? i'm _so_ glad you asked :) please note - for all of these i'm keenly aware that GPG signing is required (and nicolas has pointed out that you only need a 20-byte hash to be securely transferred by some OOB mechanism) * distribution of large mailing lists and reduction of load on SMTP servers by adding in a firebreak layer where the SMTP data goes into a git repository first, then is extracted on the other side. users may choose to download the mailing list using git over a peer-to-peer network and then use the exact same software that the mailing list server is running, thus reducing the load on the web front-end. if you then choose also to allow users to GPG-sign commits to the same git repository, you have the possibility of reducing the load on the SMTP servers *as well*. _and_ a group of users can operate in "offline" mode whilst still being able to collaborate (by sharing the git repo between themselves on an isolated LAN) _and_ when one of them goes back "online", all their commits sync up, and the rest of the world becomes aware of that group's offline discussion. * distributed wikis. there are lots of wikis now using git: ikiwiki is one, and moinmoin can also be configured to use git. so, wikis have already solved the "conflict" problem, in particular i know that joey is a smart bunny and has solved conflict resolution in ikiwiki. that makes it possible to simply turn an "ordinary" wiki into a "peer-to-peer" wiki by merely inserting git-p2p underneath. * distributed bugtrackers. the one that i know of which i believe would work straight away is the ikiwiki "bug" plugin. the rest i need to investigate: i know of at least one that's based on git that i haven't looked at for a loong while (ditrack) - but the principle is very straightforward: create bugs by UUID, commit, distribute. if you want a "central" numbering scheme then all that's needed is for a "central" service to allocate a "central" number - a symlink to the UUID would do - and you're done. * of course there's source management for other projects other than linux-2.6 :) there's plenty more ideas out there, but the primary ones i'm interested in are the ones where "traditional" software development tools are being used which are utterly dependent on the client-server paradigm. for reasons i won't explain as it's not relevant to this technical discussion list, this is making me feel a bit twitchy [free software development being dependent on the client-server paradigm, that is]. l. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html