usage for git-p2p (was: git pack/unpack over bittorrent - works!)

From: Luke Kenneth Casson Leighton <luke.leighton@gmail.com>
Date: Sep 4, 2010, 11:54 UTC
Message-ID: <AANLkTin0-Zjy7Chvntf2pNj5iCQ-4Y5u=bu8r7DSejeu@mail.gmail.com>

On Sat, Sep 4, 2010 at 2:52 AM, Artur Skawina <art.08.09@gmail.com> 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.