On Wed, Sep 1, 2010 at 11:04 PM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On Thu, Sep 2, 2010 at 12:36 AM, Luke Kenneth Casson Leighton > <luke.leighton@xxxxxxxxx> wrote: >> http://gitorious.org/python-libbittorrent/pybtlib >> >> hurrah - success! git fsck shows a "dangling commit"! >> >> so, as a proof-of-concept, 400 lines of python code plus a bittorrent >> library shows that it's possible to create a peer-to-peer distributed >> version of "git fetch", by treating the pack objects as "files to be >> shared". > > You should have a look at gittorrent [1] (and finish it too if you are > interested). it's in perl, and has been shelved afaik. sam (hi sam, you still here? :) abandoned bittorrent as the underlying mechanism, and i disagree with that decision, hence why i created what i have, to prove that it's viable. so a) i don't do perl so would need to re-create what's been done (which i don't understand, and, because it's incomplete, i can't do a perl-to-python translation and "have something working") b) i don't believe in reinventing the wheel ESPECIALLY on something as complex as peer-to-peer file distribution. cameron dale created apt-p2p which is a recreation of a peer-to-peer file distribution mechanism, and, not surprisingly, it's slow and problematic. > There were discussions whether a pack is stable enough to > be shared like this, it seems to be. as long as each version of git produces the exact same pack object, off of the command "git pack-objects --all --stdout --thin {ref} < {objref}" is that what you're referring to? because if it isn't, then yes, the sharing of files (named by a virtual filename of packs/{ref}/{objref} of course) which _might_ have differences, yeah, it becomes a bit of a fuck-up. > one of the reason "commit reel" was introduced. ah _ha_. i need to look that up. will get back to you. 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