From: Jon Seymour Date: Wed, 22 Apr 2009 09:22:09 GMT Subject: A system administration use case for git Message-ID: <2cfc40320904220222ub9b95f8o35afcddb0390fe1b@mail.gmail.com> In-Reply-To: <2cfc40320904220208g5acc2200w6144668ba2da5a09@mail.gmail.com> 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 wrote: > On Wed, Apr 22, 2009 at 10:33 AM, Jon Seymour 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@gmail.com >  martin@laptop.org -- School Server Architect >  - ask interesting questions >  - don't get distracted with shiny stuff  - working code first >  - http://wiki.laptop.org/go/User:Martinlanghoff >