{"thread":{"id":"23495","subject":"Using a git repository on the root directory","startedAt":"2010-04-16T20:44:20Z","lastAt":"2010-04-17T12:55:35Z","messageCount":9,"participants":["Miguel Ramos","Gabriel Filion","david@lang.hm","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139696","messageId":"q2k3e2876431004161344vfff638a7ncfa74aa0e3b979dc@mail.gmail.com","threadId":"23495","inReplyTo":null,"subject":"Using a git repository on the root directory","fromName":"Miguel Ramos","fromEmail":"mail@miguel.ramos.name","sentAt":"2010-04-16T20:44:20Z","receivedAt":"2010-04-16T20:44:20Z","isPatch":false,"sender":{"key":"mail@miguel.ramos.name","avatar":null},"body":"Hi,\n\nIs it possible with git to use a git repository on the root directory?\nI'm trying to replace subversion doing this.\nI have a populated repository elsewhere, I can clone this to an empty\ndirectory and then move .git to / to work around the demand that the\ntarget directory is empty and at the same time avoid overwriting\nfiles.\nI used this method before to get my home directory versioned with\nsuccess, so far.\n\nWhen I'm on the root directory, things seem to work minimally. I do\ngit status, etc, and get the expected results.\nHowever, if I change say to /etc, or any other directory, for that\nmatter, then git status tells me that every file in the repository is\ndeleted.\nAdding files doesn't work, nothing works at all.\n\nI know this is an unforeseen use of git, however, unforeseen might not\nimply forbidden.\nI'm pretty disappointed I couldn't get it working.\n\nSo the motivation for this posting is twofold:\n- Is this possible in some other way, or did I do something wrong (I'm\nnew to git) ?\n- I find the resulting behaviour pretty curious, maybe someone who\nknows how git works can explain why this is the resulting behaviour.\n\nThanks,\n\n-- \nMiguel Ramos <mail@miguel.ramos.name>\nPGP A006A14C\n"},{"id":"139715","messageId":"4BC9364D.7020204@gmail.com","threadId":"23495","inReplyTo":"q2k3e2876431004161344vfff638a7ncfa74aa0e3b979dc@mail.gmail.com","subject":"Re: Using a git repository on the root directory","fromName":"Gabriel Filion","fromEmail":"lelutin@gmail.com","sentAt":"2010-04-17T04:17:17Z","receivedAt":"2010-04-17T04:17:17Z","isPatch":false,"sender":{"key":"lelutin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/108728?v=4"},"body":"On 2010-04-16 16:44, Miguel Ramos wrote:\n> Hi,\n> \n> Is it possible with git to use a git repository on the root directory?\n> I'm trying to replace subversion doing this.\n> I used this method before to get my home directory versioned with\n> success, so far.\n> \n\nAlthough I'll give comments on the rest, is it really relvant to put all\nof the filesystem into a version control system? From a system\nadministrator's point of view, backing up is more about keeping copies\nof what's important in the computer than about versioning every tiny\nchange in the file system.\n\nOne example of something that is weird to backup is /var . It contains\ndata that will almost certainly always change.\n\nA simpler thing to do if you'd like to be able to reinstall a computer\nreal quick would be to make an image of the computer (call it a ghost, a\ndd of all the disk or whatever) and to establish a backup only for the\nsensible data (say, for an LDAP server, you would backup ldap's ldiff\nfiles and configuration). Then, restoring from a crash would just mean\nto reinstall with the image of the disk and to restore the latest backup.\n\n> When I'm on the root directory, things seem to work minimally. I do\n> git status, etc, and get the expected results.\n> However, if I change say to /etc, or any other directory, for that\n> matter, then git status tells me that every file in the repository is\n> deleted.\n> Adding files doesn't work, nothing works at all.\n> \n\nThis sounds like an issue with finding the actual .git directory when\nyou are in /etc. is this directory under a different partition than / ?\n\n> I have a populated repository elsewhere, I can clone this to an empty\n> directory and then move .git to / to work around the demand that the\n> target directory is empty and at the same time avoid overwriting\n> files.\n\nso, you're cloning to some temp dir, then moving temp/.git to / and then\nusing something like git checkout HEAD some/file/somewhere ?\n\n> I know this is an unforeseen use of git, however, unforeseen might not\n> imply forbidden.\n> I'm pretty disappointed I couldn't get it working.\n> \n> So the motivation for this posting is twofold:\n> - Is this possible in some other way, or did I do something wrong (I'm\n> new to git) ?\n\nCheck out the bup project[1], it uses the packfile format from git to\ncompress data but its focus is more on keeping versions of arbitrary\ndata rather than code files. it's still very new and lacks some\nimportant features but it sure is promising.\n\n[1] : http://github.com/apenwarr/bup\n\n-- \nGabriel Filion\n"},{"id":"139716","messageId":"alpine.DEB.2.01.1004162120490.16996@asgard.lang.hm","threadId":"23495","inReplyTo":"4BC9364D.7020204@gmail.com","subject":"Re: Using a git repository on the root directory","fromName":"","fromEmail":"david@lang.hm","sentAt":"2010-04-17T04:45:00Z","receivedAt":"2010-04-17T04:45:00Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 17 Apr 2010, Gabriel Filion wrote:\n\n> On 2010-04-16 16:44, Miguel Ramos wrote:\n>> Hi,\n>>\n>> Is it possible with git to use a git repository on the root directory?\n>> I'm trying to replace subversion doing this.\n>> I used this method before to get my home directory versioned with\n>> success, so far.\n>>\n>\n> Although I'll give comments on the rest, is it really relvant to put all\n> of the filesystem into a version control system? From a system\n> administrator's point of view, backing up is more about keeping copies\n> of what's important in the computer than about versioning every tiny\n> change in the file system.\n\nevery tiny change in the filesystem could be important. it takes a lot of \ntime to examine every package your distro creates to be sure that you know \nwhat files in it are important and what ones aren't.\n\nIn addition, if you need the ability to recreate a system later \n(potentially years later, after the distro mirrors have stopped carrying \nthat version), even the binaries can be important.\n\n> One example of something that is weird to backup is /var . It contains\n> data that will almost certainly always change.\n\nthat's what .gitignore is for\n\n> A simpler thing to do if you'd like to be able to reinstall a computer\n> real quick would be to make an image of the computer (call it a ghost, a\n> dd of all the disk or whatever) and to establish a backup only for the\n> sensible data (say, for an LDAP server, you would backup ldap's ldiff\n> files and configuration). Then, restoring from a crash would just mean\n> to reinstall with the image of the disk and to restore the latest backup.\n\nif you do this you run the risk of missing some critical file from your \nbackup\n\nyour approach is 'back up only what I know I need to', using git and \n.gitignore it becomes 'back up everything except what I know I don't want \nto' (and there is a surprising amount of stuff in /var that you may need \nto backup)\n\nif you have one very standard image then you may have a really good image \nto use, but if you want more variety in your systems the git approach \ngives you automatic deduplication of your backed up data, as well as very \nefficient delta compression between similar files on different systems.\n\nthe ease in maintaining replicas of the data is just another bonus.\n\nit may not suit your environment, but there are some very attractive \nfeatures here. Compare this to any backup software and (except for git not \nstoring permissions) you will find that the feature sets look very \nsimilar. After all, in both cases you are archiving data so that you can \ngo back in history as needed so it's substantially the same problem\n\nDavid Lang\n\n>> When I'm on the root directory, things seem to work minimally. I do\n>> git status, etc, and get the expected results.\n>> However, if I change say to /etc, or any other directory, for that\n>> matter, then git status tells me that every file in the repository is\n>> deleted.\n>> Adding files doesn't work, nothing works at all.\n>>\n>\n> This sounds like an issue with finding the actual .git directory when\n> you are in /etc. is this directory under a different partition than / ?\n>\n>> I have a populated repository elsewhere, I can clone this to an empty\n>> directory and then move .git to / to work around the demand that the\n>> target directory is empty and at the same time avoid overwriting\n>> files.\n>\n> so, you're cloning to some temp dir, then moving temp/.git to / and then\n> using something like git checkout HEAD some/file/somewhere ?\n>\n>> I know this is an unforeseen use of git, however, unforeseen might not\n>> imply forbidden.\n>> I'm pretty disappointed I couldn't get it working.\n>>\n>> So the motivation for this posting is twofold:\n>> - Is this possible in some other way, or did I do something wrong (I'm\n>> new to git) ?\n>\n> Check out the bup project[1], it uses the packfile format from git to\n> compress data but its focus is more on keeping versions of arbitrary\n> data rather than code files. it's still very new and lacks some\n> important features but it sure is promising.\n>\n> [1] : http://github.com/apenwarr/bup\n>\n>\n"},{"id":"139725","messageId":"m3zl12eaif.fsf@localhost.localdomain","threadId":"23495","inReplyTo":"q2k3e2876431004161344vfff638a7ncfa74aa0e3b979dc@mail.gmail.com","subject":"Re: Using a git repository on the root directory","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-17T08:42:35Z","receivedAt":"2010-04-17T08:42:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Miguel Ramos <mail@miguel.ramos.name> writes:\n\n> Is it possible with git to use a git repository on the root directory?\n> I'm trying to replace subversion doing this.\n> I have a populated repository elsewhere, I can clone this to an empty\n> directory and then move .git to / to work around the demand that the\n> target directory is empty and at the same time avoid overwriting\n> files.\n> I used this method before to get my home directory versioned with\n> success, so far.\n> \n> When I'm on the root directory, things seem to work minimally. I do\n> git status, etc, and get the expected results.\n> However, if I change say to /etc, or any other directory, for that\n> matter, then git status tells me that every file in the repository is\n> deleted.\n> Adding files doesn't work, nothing works at all.\n> \n> I know this is an unforeseen use of git, however, unforeseen might not\n> imply forbidden.\n> I'm pretty disappointed I couldn't get it working.\n\nThe 'nd/root-git' branch (merged into 'master' as v1.7.1-rc0~89)\nmight have addressed the issue you are seeing.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"139736","messageId":"t2g3e2876431004170415r71d5f834z3bfdedfaec076c6c@mail.gmail.com","threadId":"23495","inReplyTo":"alpine.DEB.2.01.1004162120490.16996@asgard.lang.hm","subject":"Re: Using a git repository on the root directory","fromName":"Miguel Ramos","fromEmail":"mail@miguel.ramos.name","sentAt":"2010-04-17T11:15:55Z","receivedAt":"2010-04-17T11:15:55Z","isPatch":false,"sender":{"key":"mail@miguel.ramos.name","avatar":null},"body":"2010/4/17  <david@lang.hm>:\n> On Sat, 17 Apr 2010, Gabriel Filion wrote:\n>\n>> On 2010-04-16 16:44, Miguel Ramos wrote:\n>>>\n>>> Hi,\n>>>\n>>> Is it possible with git to use a git repository on the root directory?\n>>> I'm trying to replace subversion doing this.\n>>> I used this method before to get my home directory versioned with\n>>> success, so far.\n>>>\n>>\n>> Although I'll give comments on the rest, is it really relvant to put all\n>> of the filesystem into a version control system? From a system\n>> administrator's point of view, backing up is more about keeping copies\n>> of what's important in the computer than about versioning every tiny\n>> change in the file system.\n>\n> every tiny change in the filesystem could be important. it takes a lot of\n> time to examine every package your distro creates to be sure that you know\n> what files in it are important and what ones aren't.\n>\n> In addition, if you need the ability to recreate a system later (potentially\n> years later, after the distro mirrors have stopped carrying that version),\n> even the binaries can be important.\n\nNo, but that's not my intention, I should have explained myself better.\n\nWhat I mean, and what I've been doing with svn, is to keep versioned\ncopies of configuration files only; files in general would never be\nadded to the repository.\nThat's why a VCS would be (and svn has been) useful.\n\nCan you see how useful it is, now?\nYou can have the same configuration files on several machines, you can\nhave different branches for machines which are configured differently,\nmerge in changes done on different branches.\nReally, it's great, I've been using svn for this, and I'd never want to go back.\nI can install an OS on a machine and get everything up and running very quickly.\n\nThe only thing is that not all configuration files are in /etc, some\nare in /usr/src/linux, some in /boot, /var, etc, that's why the root\nof the repository is root and not something else.\nAlso, although I could have different repositories for each of these\nsubtrees, because I use FreeBSD and linux, some files in one are in\n/etc and in the other in /usr/local/etc, etc. That's why the root of\nthe repository is root.\n\nUsing a VCS almost totally fits this use case.\nConfiguration files are text, most often only one or two lines change,\nI want to see diffs often, branching and merging is very important.\nMoreover, using a centralized VCS is very artificial, and is only good\nto centralize backups.\nIt only fits less well because git was thought out in a model where\nevery file in the repository directory should either belong to the\nrepository or be some kind of trash put in gitignore; this is not the\ncase here.\n\n>> One example of something that is weird to backup is /var . It contains\n>> data that will almost certainly always change.\n\nThat's not weird to backup, that's the data you typically want to\nbackup frequently: data that keeps changing.\nNot /var/run or /var/cache, which are trash after a crash, of course.\nWhy backup /usr, for instance, which you can recover by re-installing\napplications?\n\nBut my use case isn't backups.\n\n> that's what .gitignore is for\n>\n>> A simpler thing to do if you'd like to be able to reinstall a computer\n>> real quick would be to make an image of the computer (call it a ghost, a\n>> dd of all the disk or whatever) and to establish a backup only for the\n>> sensible data (say, for an LDAP server, you would backup ldap's ldiff\n>> files and configuration). Then, restoring from a crash would just mean\n>> to reinstall with the image of the disk and to restore the latest backup.\n>\n> if you do this you run the risk of missing some critical file from your\n> backup\n>\n> your approach is 'back up only what I know I need to', using git and\n> .gitignore it becomes 'back up everything except what I know I don't want\n> to' (and there is a surprising amount of stuff in /var that you may need to\n> backup)\n>\n> if you have one very standard image then you may have a really good image to\n> use, but if you want more variety in your systems the git approach gives you\n> automatic deduplication of your backed up data, as well as very efficient\n> delta compression between similar files on different systems.\n>\n> the ease in maintaining replicas of the data is just another bonus.\n>\n> it may not suit your environment, but there are some very attractive\n> features here. Compare this to any backup software and (except for git not\n> storing permissions) you will find that the feature sets look very similar.\n> After all, in both cases you are archiving data so that you can go back in\n> history as needed so it's substantially the same problem\n>\n> David Lang\n\nWell, David, you certainly made a good case defending using a VCS for\nfilesystems.\nHowever, a versioned filesystem should be more adequate for that.\nWhy would one want diffs, patches, branches, merges for the entire filesystem?\nIf only there was one in general use...\nFreeBSD had one, LFS, but they set it aside, I think it was buggy.\n\n>>> When I'm on the root directory, things seem to work minimally. I do\n>>> git status, etc, and get the expected results.\n>>> However, if I change say to /etc, or any other directory, for that\n>>> matter, then git status tells me that every file in the repository is\n>>> deleted.\n>>> Adding files doesn't work, nothing works at all.\n>>>\n>>\n>> This sounds like an issue with finding the actual .git directory when\n>> you are in /etc. is this directory under a different partition than / ?\n\nNo, it's not. And it happens on every other directory other than root.\nIt looks like it finds the .git directory, but then has problems\nfinding the actual files.\nIt's not a cross filesystem problem.\n\n>>> I have a populated repository elsewhere, I can clone this to an empty\n>>> directory and then move .git to / to work around the demand that the\n>>> target directory is empty and at the same time avoid overwriting\n>>> files.\n>>\n>> so, you're cloning to some temp dir, then moving temp/.git to / and then\n>> using something like git checkout HEAD some/file/somewhere ?\n\nYes, that's it.\nThat \"technique\" is working for me now for the home directory repository.\n\nWith svn, I used to do a svn checkout --force, that would not complain\nabout existing directories and files (which were overwritten, and that\nwas exactly what I needed).\n\n>>> I know this is an unforeseen use of git, however, unforeseen might not\n>>> imply forbidden.\n>>> I'm pretty disappointed I couldn't get it working.\n>>>\n>>> So the motivation for this posting is twofold:\n>>> - Is this possible in some other way, or did I do something wrong (I'm\n>>> new to git) ?\n>>\n>> Check out the bup project[1], it uses the packfile format from git to\n>> compress data but its focus is more on keeping versions of arbitrary\n>> data rather than code files. it's still very new and lacks some\n>> important features but it sure is promising.\n>>\n>> [1] : http://github.com/apenwarr/bup\n\nHmmm...\nthanks but I need diffs, branches and merges.\n\n-- \nMiguel Ramos <mail@miguel.ramos.name>\nPGP A006A14C\n"},{"id":"139738","messageId":"y2y3e2876431004170439o15fbe62dv612157226d978fa5@mail.gmail.com","threadId":"23495","inReplyTo":"m3zl12eaif.fsf@localhost.localdomain","subject":"Re: Using a git repository on the root directory","fromName":"Miguel Ramos","fromEmail":"mail@miguel.ramos.name","sentAt":"2010-04-17T11:39:57Z","receivedAt":"2010-04-17T11:39:57Z","isPatch":false,"sender":{"key":"mail@miguel.ramos.name","avatar":null},"body":"2010/4/17 Jakub Narebski <jnareb@gmail.com>:\n> Miguel Ramos <mail@miguel.ramos.name> writes:\n>\n>> Is it possible with git to use a git repository on the root directory?\n>> I'm trying to replace subversion doing this.\n>> I have a populated repository elsewhere, I can clone this to an empty\n>> directory and then move .git to / to work around the demand that the\n>> target directory is empty and at the same time avoid overwriting\n>> files.\n>> I used this method before to get my home directory versioned with\n>> success, so far.\n>>\n>> When I'm on the root directory, things seem to work minimally. I do\n>> git status, etc, and get the expected results.\n>> However, if I change say to /etc, or any other directory, for that\n>> matter, then git status tells me that every file in the repository is\n>> deleted.\n>> Adding files doesn't work, nothing works at all.\n>>\n>> I know this is an unforeseen use of git, however, unforeseen might not\n>> imply forbidden.\n>> I'm pretty disappointed I couldn't get it working.\n>\n> The 'nd/root-git' branch (merged into 'master' as v1.7.1-rc0~89)\n> might have addressed the issue you are seeing.\n>\n> --\n> Jakub Narebski\n> Poland\n> ShadeHawk on #git\n\nYes, that's exactly it.\nI tried out v1.7.1-rc1 and it works.\n\nGood thing this got merged into the main branch.\nI'm putting * in /.git/info/exclude, so adding files to the repository\nmust be explicit.\nIt seems to work, but if anyone knows of any downside to doing this,\nplease tell me, I'm new to git.\n\nThanks\n\n-- \nMiguel Ramos <mail@miguel.ramos.name>\nPGP A006A14C\n"},{"id":"139739","messageId":"alpine.DEB.2.01.1004170439170.16996@asgard.lang.hm","threadId":"23495","inReplyTo":"t2g3e2876431004170415r71d5f834z3bfdedfaec076c6c@mail.gmail.com","subject":"Re: Using a git repository on the root directory","fromName":"","fromEmail":"david@lang.hm","sentAt":"2010-04-17T11:48:38Z","receivedAt":"2010-04-17T11:48:38Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 17 Apr 2010, Miguel Ramos wrote:\n\n> Well, David, you certainly made a good case defending using a VCS for\n> filesystems.\n> However, a versioned filesystem should be more adequate for that.\n\na versioned filesystem will not let you easily clone or backup your \nsystem. a versioned filesystem could be a nice UI to access a DVCS that \nwould give you this sort of ability\n\n> Why would one want diffs, patches, branches, merges for the entire filesystem?\n\nthese all seem like very useful things to me\n\ndiffs to find out what changed when a system gets broken, or after \nsomething new is installed.\n\npatches could be a way to either install software, or to propogate updates \nbetween systems.\n\nbranches could easily be different systems\n\nmerges are for when you have two systems each doing one job and you want \nto combine them onto one piece of hardware (could could do it with \nvirtualization, if you are willing to pay the overhead). you wouldn't want \nto merge the binary files, but you would want to merge the branches that \ncontain binary files.\n\nthere are many reasons why you don't just use your linux distro tools to \nmanage large numbers of machines and configurations.\n\nDavid Lang\n"},{"id":"139742","messageId":"v2l3e2876431004170458ib2d40b28he1fb56906f94a7ed@mail.gmail.com","threadId":"23495","inReplyTo":"alpine.DEB.2.01.1004170439170.16996@asgard.lang.hm","subject":"Re: Using a git repository on the root directory","fromName":"Miguel Ramos","fromEmail":"mail@miguel.ramos.name","sentAt":"2010-04-17T11:58:45Z","receivedAt":"2010-04-17T11:58:45Z","isPatch":false,"sender":{"key":"mail@miguel.ramos.name","avatar":null},"body":"2010/4/17  <david@lang.hm>:\n> On Sat, 17 Apr 2010, Miguel Ramos wrote:\n>\n>> Well, David, you certainly made a good case defending using a VCS for\n>> filesystems.\n>> However, a versioned filesystem should be more adequate for that.\n>\n> a versioned filesystem will not let you easily clone or backup your system.\n> a versioned filesystem could be a nice UI to access a DVCS that would give\n> you this sort of ability\n>\n>> Why would one want diffs, patches, branches, merges for the entire\n>> filesystem?\n>\n> these all seem like very useful things to me\n>\n> diffs to find out what changed when a system gets broken, or after something\n> new is installed.\n>\n> patches could be a way to either install software, or to propogate updates\n> between systems.\n>\n> branches could easily be different systems\n>\n> merges are for when you have two systems each doing one job and you want to\n> combine them onto one piece of hardware (could could do it with\n> virtualization, if you are willing to pay the overhead). you wouldn't want\n> to merge the binary files, but you would want to merge the branches that\n> contain binary files.\n>\n> there are many reasons why you don't just use your linux distro tools to\n> manage large numbers of machines and configurations.\n>\n> David Lang\n\nYes, you certainly are right.\nIt does open up a set of new possibilities.\nEven better if it was based on a binary diff, because otherwise you\neither had to be very conservative updating software or run out of\nspace.\n\n-- \nMiguel Ramos <mail@miguel.ramos.name>\nPGP A006A14C\n"},{"id":"139746","messageId":"alpine.DEB.2.01.1004170548440.16996@asgard.lang.hm","threadId":"23495","inReplyTo":"v2l3e2876431004170458ib2d40b28he1fb56906f94a7ed@mail.gmail.com","subject":"Re: Using a git repository on the root directory","fromName":"","fromEmail":"david@lang.hm","sentAt":"2010-04-17T12:55:35Z","receivedAt":"2010-04-17T12:55:35Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 17 Apr 2010, Miguel Ramos wrote:\n\n> 2010/4/17  <david@lang.hm>:\n>> On Sat, 17 Apr 2010, Miguel Ramos wrote:\n>>\n>>> Well, David, you certainly made a good case defending using a VCS for\n>>> filesystems.\n>>> However, a versioned filesystem should be more adequate for that.\n>>\n>> a versioned filesystem will not let you easily clone or backup your system.\n>> a versioned filesystem could be a nice UI to access a DVCS that would give\n>> you this sort of ability\n>>\n>>> Why would one want diffs, patches, branches, merges for the entire\n>>> filesystem?\n>>\n>> these all seem like very useful things to me\n>>\n>> diffs to find out what changed when a system gets broken, or after something\n>> new is installed.\n>>\n>> patches could be a way to either install software, or to propogate updates\n>> between systems.\n>>\n>> branches could easily be different systems\n>>\n>> merges are for when you have two systems each doing one job and you want to\n>> combine them onto one piece of hardware (could could do it with\n>> virtualization, if you are willing to pay the overhead). you wouldn't want\n>> to merge the binary files, but you would want to merge the branches that\n>> contain binary files.\n>>\n>> there are many reasons why you don't just use your linux distro tools to\n>> manage large numbers of machines and configurations.\n>>\n>> David Lang\n>\n> Yes, you certainly are right.\n> It does open up a set of new possibilities.\n> Even better if it was based on a binary diff, because otherwise you\n> either had to be very conservative updating software or run out of\n> space.\n\ngit works just fine on doing diffs of binary files.\n\nshallow clones on individual systems would avoid the need to have \nhuge amounts of storage on an individual system for history, and with a \nseparate branch for each system you only have to have the files for your \nsystem locally, but on systems where you keep all the branches disk space \nis usually not that big a problem.\n\nDavid Lang\n"}]}