On Wed, Apr 22, 2009 at 11:22 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > One disadvantage of that approach is if the file system is very large > and only has a few deltas, then I effectively have to have two copies > of the reference file system - one in the GIT repo and one that I can You could minimise the on-disk footprint -- and protect it from concurrent access (concurrent change) by using a hardlinked tree on the destination side. rsync knows to break hardlinks, etc. Currently, you can't "rsync into git" which would save you that step. It's a ton of work to do that -- if anyone is planning on working on something like that, perhaps writing directly into the fast-import protocol is a good shortcut. I'd like to have something like that for my OLPC School Server, which could benefit from using git as the backup backend -- it currently uses hardlinked directories. > In an ideal world, storage requirements at the other place would be > those of the reference file system + those of the various deltas, but > no more. rsync + hardlinked trees + git gets you quite close to that. cheers, m -- martin.langhoff@xxxxxxxxx martin@xxxxxxxxxx -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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