Martin, 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 damage on a regular basis with rsync for the purposes calculating the git deltas. I know I can then use git to repair the damage, but then the reference has to be protected from concurrent access. I'd prefer not to have to maintain a copy of the tree that has to be "damaged" on a regular basis and also if I didn't have to maintain a copy of the git objects for identical files. 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. jon seymour On Wed, Apr 22, 2009 at 6:48 PM, Martin Langhoff <martin.langhoff@xxxxxxxxx> wrote: > On Wed, Apr 22, 2009 at 10:33 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: >> Hello all, it's been quite a while. >> It'd be nice to do this on arbitrary (non-git-controlled) file system tree: >> >> * calculate the git hashes of the tree (without making copies of the >> files in the tree) >> * archive the tree hashes >> * rsync the tree hashes to another place >> * work out which files aren't available in the other place's git repo >> * rsync those files the the other place > > Steps: > > 1 - rsync to the "other place" > 2 - use the git repo in that "other place" > 3 - if the tree hashes are needed "here", copy them from the "other > place" git to here. > > rsync + git = awesomenesssssss > > > > > -- > 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