{"thread":{"id":"32117","subject":"Fwd: Local clones aka forks disk size optimization","startedAt":"2012-11-14T23:42:00Z","lastAt":"2012-11-18T17:18:56Z","messageCount":13,"participants":["Javier Domingo","Andrew Ardill","Sitaram Chamarty","Michael J Gruber","Pyeron, Jason J CTR (US)","Enrico Weigelt","Jörg Rosenkranz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203228","messageId":"CALZVapmO61d8yXfXXGx6Qc444ka+8n7HabuNRt0rJdE5qy_7aQ@mail.gmail.com","threadId":"32117","inReplyTo":"CALZVapmG+HL0SQx8zx=Cfz5pWv84hJq90x-7VdjA0m2Z4dC34A@mail.gmail.com","subject":"Fwd: Local clones aka forks disk size optimization","fromName":"Javier Domingo","fromEmail":"javierdo1@gmail.com","sentAt":"2012-11-14T23:42:00Z","receivedAt":"2012-11-14T23:42:00Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"Hi,\n\nI have come up with this while doing some local forks for work.\nCurrently, when you clone a repo using a path (not file:/// protocol)\nyou get all the common objects linked.\n\nBut as you work, each one will continue growing on its way, although\nthey may have common objects.\n\nIs there any way to avoid this? I mean, can something be done in git,\nthat it checks for (when pulling) the same objects in the other forks?\n\nThought this doesn't make much sense in clients, when you have to\nmaintain 20 forks of very big projects in server side, it eats\nprecious disk space.\n\nI don't know how if this should have [RFC] in the subject or what. But\nhere is my idea.\n\nAs hardlinking is already done by git, if it checked for how many\nlinks there are for its files, it would be able to find other dirs\nwhere to search. The easier way is checking for the most ancient pack.\n\nHope you like this idea,\n\nJavier Domingo\n"},{"id":"203234","messageId":"CAH5451nW2esQR8XaAttT3tYJZEw1Nj3OEMgkHsMZrZDxhcRXHw@mail.gmail.com","threadId":"32117","inReplyTo":"CALZVapmO61d8yXfXXGx6Qc444ka+8n7HabuNRt0rJdE5qy_7aQ@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-11-15T00:18:27Z","receivedAt":"2012-11-15T00:18:27Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 15 November 2012 10:42, Javier Domingo wrote:\n> Hi,\n>\n> I have come up with this while doing some local forks for work.\n> Currently, when you clone a repo using a path (not file:/// protocol)\n> you get all the common objects linked.\n>\n> But as you work, each one will continue growing on its way, although\n> they may have common objects.\n>\n> Is there any way to avoid this? I mean, can something be done in git,\n> that it checks for (when pulling) the same objects in the other forks?\n\nHave you seen alternates? From [1]:\n\n> How to share objects between existing repositories?\n> ---------------------------------------------------------------------------\n>\n> Do\n>\n> echo \"/source/git/project/.git/objects/\" > .git/objects/info/alternates\n>\n> and then follow it up with\n>\n> git repack -a -d -l\n>\n> where the '-l' means that it will only put local objects in the pack-file\n> (strictly speaking, it will put any loose objects from the alternate tree\n> too, so you'll have a fully packed archive, but it won't duplicate objects\n> that are already packed in the alternate tree).\n\n[1] https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F\n\n\nRegards,\n\nAndrew Ardill\n"},{"id":"203245","messageId":"CALZVap=kOwOpxeu8+_+5uQYZz3GNC8Ep_JeK7WCQHtu+Hn3rUw@mail.gmail.com","threadId":"32117","inReplyTo":"CAH5451nW2esQR8XaAttT3tYJZEw1Nj3OEMgkHsMZrZDxhcRXHw@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Javier Domingo","fromEmail":"javierdo1@gmail.com","sentAt":"2012-11-15T00:40:58Z","receivedAt":"2012-11-15T00:40:58Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"Hi Andrew,\n\nThe problem about that, is that if I want to delete the first repo, I\nwill loose objects... Or does that repack also hard-link the objects\nin other repos? I don't want to accidentally loose data, so it would\nbe nice that althought avoided to repack things, it would also\nhardlink them.\nJavier Domingo\n\n\n2012/11/15 Andrew Ardill :\n> On 15 November 2012 10:42, Javier Domingo wrote:\n>> Hi,\n>>\n>> I have come up with this while doing some local forks for work.\n>> Currently, when you clone a repo using a path (not file:/// protocol)\n>> you get all the common objects linked.\n>>\n>> But as you work, each one will continue growing on its way, although\n>> they may have common objects.\n>>\n>> Is there any way to avoid this? I mean, can something be done in git,\n>> that it checks for (when pulling) the same objects in the other forks?\n>\n> Have you seen alternates? From [1]:\n>\n>> How to share objects between existing repositories?\n>> ---------------------------------------------------------------------------\n>>\n>> Do\n>>\n>> echo \"/source/git/project/.git/objects/\" > .git/objects/info/alternates\n>>\n>> and then follow it up with\n>>\n>> git repack -a -d -l\n>>\n>> where the '-l' means that it will only put local objects in the pack-file\n>> (strictly speaking, it will put any loose objects from the alternate tree\n>> too, so you'll have a fully packed archive, but it won't duplicate objects\n>> that are already packed in the alternate tree).\n>\n> [1] https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F\n>\n>\n> Regards,\n>\n> Andrew Ardill\n"},{"id":"203246","messageId":"CAH5451m4saVa7-NLbVbXp7q8ca5_0N4FLk3wYaqxLT=AE5frbw@mail.gmail.com","threadId":"32117","inReplyTo":"CALZVap=kOwOpxeu8+_+5uQYZz3GNC8Ep_JeK7WCQHtu+Hn3rUw@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-11-15T00:53:19Z","receivedAt":"2012-11-15T00:53:19Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 15 November 2012 11:40, Javier Domingo wrote:\n> Hi Andrew,\n>\n> The problem about that, is that if I want to delete the first repo, I\n> will loose objects... Or does that repack also hard-link the objects\n> in other repos? I don't want to accidentally loose data, so it would\n> be nice that althought avoided to repack things, it would also\n> hardlink them.\n\nHi Javier, check out the section below the one I linked earlier:\n\n> How to stop sharing objects between repositories?\n>\n> To copy the shared objects into the local repository, repack without the -l flag\n>\n> git repack -a\n>\n> Then remove the pointer to the alternate object store\n>\n> rm .git/objects/info/alternates\n>\n> (If the repository is edited between the two steps, it could become corrupted\n> when the alternates file is removed. If you're unsure, you can use git fsck to\n> check for corruption. If things go wrong, you can always recover by replacing\n> the alternates file and starting over).\n\nRegards,\n\nAndrew Ardill\n"},{"id":"203247","messageId":"CALZVapmBM78UtjAiNm2VoeWuetCiyxN70mTxbG14SQh5a5RCeQ@mail.gmail.com","threadId":"32117","inReplyTo":"CAH5451m4saVa7-NLbVbXp7q8ca5_0N4FLk3wYaqxLT=AE5frbw@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Javier Domingo","fromEmail":"javierdo1@gmail.com","sentAt":"2012-11-15T01:15:07Z","receivedAt":"2012-11-15T01:15:07Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"Hi Andrew,\n\nDoing this would require I got tracked which one comes from which. So\nit would imply some logic (and db) over it. With the hardlinking way,\nit wouldn't require anything. The idea is that you don't have to do\nanything else in the server.\n\nI understand that it would be imposible to do it for windows users\n(but using cygwin), but for *nix ones yes...\nJavier Domingo\n\n\n2012/11/15 Andrew Ardill :\n> On 15 November 2012 11:40, Javier Domingo wrote:\n>> Hi Andrew,\n>>\n>> The problem about that, is that if I want to delete the first repo, I\n>> will loose objects... Or does that repack also hard-link the objects\n>> in other repos? I don't want to accidentally loose data, so it would\n>> be nice that althought avoided to repack things, it would also\n>> hardlink them.\n>\n> Hi Javier, check out the section below the one I linked earlier:\n>\n>> How to stop sharing objects between repositories?\n>>\n>> To copy the shared objects into the local repository, repack without the -l flag\n>>\n>> git repack -a\n>>\n>> Then remove the pointer to the alternate object store\n>>\n>> rm .git/objects/info/alternates\n>>\n>> (If the repository is edited between the two steps, it could become corrupted\n>> when the alternates file is removed. If you're unsure, you can use git fsck to\n>> check for corruption. If things go wrong, you can always recover by replacing\n>> the alternates file and starting over).\n>\n> Regards,\n>\n> Andrew Ardill\n"},{"id":"203250","messageId":"CAH5451=Tk=zjkYbK0720VBkAA12VRCAE_Dx8bBkoXba60ho8AA@mail.gmail.com","threadId":"32117","inReplyTo":"CALZVapmBM78UtjAiNm2VoeWuetCiyxN70mTxbG14SQh5a5RCeQ@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-11-15T01:34:13Z","receivedAt":"2012-11-15T01:34:13Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 15 November 2012 12:15, Javier Domingo wrote:\n> Hi Andrew,\n>\n> Doing this would require I got tracked which one comes from which. So\n> it would imply some logic (and db) over it. With the hardlinking way,\n> it wouldn't require anything. The idea is that you don't have to do\n> anything else in the server.\n>\n> I understand that it would be imposible to do it for windows users\n> (but using cygwin), but for *nix ones yes...\n> Javier Domingo\n\nParaphrasing from git-clone(1):\n\nWhen cloning a repository, if the source repository is specified with\n/path/to/repo syntax, the default is to clone the repository by making\na copy of HEAD and everything under objects and refs directories. The\nfiles under .git/objects/ directory are hardlinked to save space when\npossible. To force copying instead of hardlinking (which may be\ndesirable if you are trying to make a back-up of your repository)\n--no-hardlinks can be used.\n\nSo hardlinks should be used where possible, and if they are not try\nupgrading Git.\n\nI think that covers all the use cases you have?\n\nRegards,\n\nAndrew Ardill\n"},{"id":"203265","messageId":"CAMK1S_ioQQWXaOO8Na=7M4QhaaUNQ8ySVM-E_2bk6m4TyvRpeA@mail.gmail.com","threadId":"32117","inReplyTo":"CAH5451=Tk=zjkYbK0720VBkAA12VRCAE_Dx8bBkoXba60ho8AA@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-11-15T03:44:10Z","receivedAt":"2012-11-15T03:44:10Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill wrote:\n> On 15 November 2012 12:15, Javier Domingo wrote:\n>> Hi Andrew,\n>>\n>> Doing this would require I got tracked which one comes from which. So\n>> it would imply some logic (and db) over it. With the hardlinking way,\n>> it wouldn't require anything. The idea is that you don't have to do\n>> anything else in the server.\n>>\n>> I understand that it would be imposible to do it for windows users\n>> (but using cygwin), but for *nix ones yes...\n>> Javier Domingo\n>\n> Paraphrasing from git-clone(1):\n>\n> When cloning a repository, if the source repository is specified with\n> /path/to/repo syntax, the default is to clone the repository by making\n> a copy of HEAD and everything under objects and refs directories. The\n> files under .git/objects/ directory are hardlinked to save space when\n> possible. To force copying instead of hardlinking (which may be\n> desirable if you are trying to make a back-up of your repository)\n> --no-hardlinks can be used.\n>\n> So hardlinks should be used where possible, and if they are not try\n> upgrading Git.\n>\n> I think that covers all the use cases you have?\n\nI am not sure it does. My understanding is this:\n\n'git clone -l' saves space on the initial clone, but subsequent pushes\nend up with the same objects duplicated across all the \"forks\"\n(assuming most of the forks keep up with some canonical repo).\n\nThe alternates mechanism can give you ongoing savings (as long as you\npush to the \"main\" repo first), but it is dangerous, in the words of\nthe git-clone manpage. You have to be confident no one will delete a\nref from the \"main\" repo and then do a gc or let it auto-gc.\n\nHe's looking for something that addresses both these issues.\n\nAs an additional idea, I suspect this is what the namespaces feature\nwas created for, but I am not sure, and have never played with it till\nnow.\n\nMaybe someone who knows namespaces very well will chip in...\n"},{"id":"203337","messageId":"50A622A9.4040709@drmicha.warpmail.net","threadId":"32117","inReplyTo":"CAMK1S_ioQQWXaOO8Na=7M4QhaaUNQ8ySVM-E_2bk6m4TyvRpeA@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-11-16T11:25:29Z","receivedAt":"2012-11-16T11:25:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Sitaram Chamarty venit, vidit, dixit 15.11.2012 04:44:\n> On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill wrote:\n>> On 15 November 2012 12:15, Javier Domingo wrote:\n>>> Hi Andrew,\n>>>\n>>> Doing this would require I got tracked which one comes from which. So\n>>> it would imply some logic (and db) over it. With the hardlinking way,\n>>> it wouldn't require anything. The idea is that you don't have to do\n>>> anything else in the server.\n>>>\n>>> I understand that it would be imposible to do it for windows users\n>>> (but using cygwin), but for *nix ones yes...\n>>> Javier Domingo\n>>\n>> Paraphrasing from git-clone(1):\n>>\n>> When cloning a repository, if the source repository is specified with\n>> /path/to/repo syntax, the default is to clone the repository by making\n>> a copy of HEAD and everything under objects and refs directories. The\n>> files under .git/objects/ directory are hardlinked to save space when\n>> possible. To force copying instead of hardlinking (which may be\n>> desirable if you are trying to make a back-up of your repository)\n>> --no-hardlinks can be used.\n>>\n>> So hardlinks should be used where possible, and if they are not try\n>> upgrading Git.\n>>\n>> I think that covers all the use cases you have?\n> \n> I am not sure it does. My understanding is this:\n> \n> 'git clone -l' saves space on the initial clone, but subsequent pushes\n> end up with the same objects duplicated across all the \"forks\"\n> (assuming most of the forks keep up with some canonical repo).\n> \n> The alternates mechanism can give you ongoing savings (as long as you\n> push to the \"main\" repo first), but it is dangerous, in the words of\n> the git-clone manpage. You have to be confident no one will delete a\n> ref from the \"main\" repo and then do a gc or let it auto-gc.\n> \n> He's looking for something that addresses both these issues.\n> \n> As an additional idea, I suspect this is what the namespaces feature\n> was created for, but I am not sure, and have never played with it till\n> now.\n> \n> Maybe someone who knows namespaces very well will chip in...\n> \n\nI dunno about namespaces, but a safe route with alternates seems to be:\n\nProvide one \"main\" clone which is bare, pulls automatically, and is\nthere to stay (no pruning), so that all others can use that as a\nreliable alternates source.\n\nMichael\n"},{"id":"203344","messageId":"871B6C10EBEFE342A772D1159D13208537AAF4EF@umechphj.easf.csd.disa.mil","threadId":"32117","inReplyTo":"CALZVapmBM78UtjAiNm2VoeWuetCiyxN70mTxbG14SQh5a5RCeQ@mail.gmail.com","subject":"RE: Local clones aka forks disk size optimization","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-16T14:55:21Z","receivedAt":"2012-11-16T14:55:21Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Javier Domingo\n> Sent: Wednesday, November 14, 2012 8:15 PM\n> \n> Hi Andrew,\n> \n> Doing this would require I got tracked which one comes from which. So\n> it would imply some logic (and db) over it. With the hardlinking way,\n> it wouldn't require anything. The idea is that you don't have to do\n> anything else in the server.\n> \n> I understand that it would be imposible to do it for windows users\n\nNot true, it is a file system issue not an os issue. FAT does not support hard links, but ext2,3,4 and NTFS do.\n\n> (but using cygwin), but for *nix ones yes...\n> Javier Domingo\n\n"},{"id":"203354","messageId":"ccb8680a-97ad-4cf8-95d0-5e21f60494f4@zcs","threadId":"32117","inReplyTo":"50A622A9.4040709@drmicha.warpmail.net","subject":"Re: Local clones aka forks disk size optimization","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-11-16T18:04:35Z","receivedAt":"2012-11-16T18:04:35Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"\n> Provide one \"main\" clone which is bare, pulls automatically, and is\n> there to stay (no pruning), so that all others can use that as a\n> reliable alternates source.\n\nThe problem here, IMHO, is the assumption, that the main repo will\nnever be cleaned up. But what to do if you dont wanna let it grow\nforever ?\n\nhmm, distributed GC is a tricky problem.\n\nmaybe it could be easier having two kind of alternates:\n\na) classical: gc+friends will drop local objects that are \n already there\nb) fallback: normal operations fetch objects if not accessible\n from anywhere else, but gc+friends do not skip objects from there.\n\nAnd extend prune machinery to put some backup of the dropped objects\nto some separate store.\n\nThis way we could use some kind of rotating archive:\n\n* GC'ed objects will be stored in the backup repo for some while\n* there are multiple active (rotating) backups kept for some time,\n each cycle, only the oldest one is dropped (and maybe objects\n in a newer backup are removed from the older ones)\n* downstream repos must be synced often enough, so removed objects\n are fetched back from the backups early enough\n\nYou could see this as some heap:\n\n* the currently active objects (directly referenced) are always\n on the top\n* once they're not referenced, they sink a lever deeper\n* when the're referenced again, they immediately jump up to the top\n* at some point in time unreferenced objects sink too deep that\n they're dropped completely\n\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"203465","messageId":"CAMK1S_hCk3QdDn8XnXVisL1i2V0iPCZBYN989JmZ3JYr7ckRrA@mail.gmail.com","threadId":"32117","inReplyTo":"ccb8680a-97ad-4cf8-95d0-5e21f60494f4@zcs","subject":"Re: Local clones aka forks disk size optimization","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-11-18T10:42:06Z","receivedAt":"2012-11-18T10:42:06Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Fri, Nov 16, 2012 at 11:34 PM, Enrico Weigelt wrote:\n>\n>> Provide one \"main\" clone which is bare, pulls automatically, and is\n>> there to stay (no pruning), so that all others can use that as a\n>> reliable alternates source.\n>\n> The problem here, IMHO, is the assumption, that the main repo will\n> never be cleaned up. But what to do if you dont wanna let it grow\n> forever ?\n\nThat's not the only problem. I believe you only get the savings when\nthe main repo gets the commits first. Which is probably ok most of\nthe time but it's worth mentioning.\n\n>\n> hmm, distributed GC is a tricky problem.\n\nExcept for one little issue (see other thread, subject line \"cloning a\nnamespace downloads all the objects\"), namespaces appear to do\neverything we want in terms of the typical use cases for alternates,\nand/or 'git clone -l', at least on the server side.\n"},{"id":"203494","messageId":"27f681a7-f87d-47b4-a512-93511b44b286@zcs","threadId":"32117","inReplyTo":"CAMK1S_hCk3QdDn8XnXVisL1i2V0iPCZBYN989JmZ3JYr7ckRrA@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-11-18T17:02:37Z","receivedAt":"2012-11-18T17:02:37Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"Hi,\n\n> That's not the only problem. I believe you only get the savings when\n> the main repo gets the commits first. Which is probably ok most of\n> the time but it's worth mentioning.\n\nWell, the saving will just be deferred to the point where the commit\nfinally went to the main repo and downstreams are gc'ed.\n\n> > hmm, distributed GC is a tricky problem.\n> \n> Except for one little issue (see other thread, subject line \"cloning\n> a\n> namespace downloads all the objects\"), namespaces appear to do\n> everything we want in terms of the typical use cases for alternates,\n> and/or 'git clone -l', at least on the server side.\n\nhmm, not sure about the actual internals, but that namespace filtering\nshould work in a way that local clone should never see (or consider)\nremote refs that are outside of the requested namespace. Perhaps that\nshould be handled entirely on server side, so all called commands treat\nthese refs as nonexisting.\n\nBy the way: what happens if one tries to clone from an broken repo\n(which has several refs pointing to nonexisting objects ?\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"203495","messageId":"CAKs0BQ7++Zqn7j=vKW3jLsi8y6UMRXXp5Jk6FsEWGzRaC+EGdg@mail.gmail.com","threadId":"32117","inReplyTo":"CAKs0BQ7RyLZr+ZU=hAC4U7xXpE0+xvORTrvfzFYb6muA2TgM4Q@mail.gmail.com","subject":"Re: Local clones aka forks disk size optimization","fromName":"Jörg Rosenkranz","fromEmail":"joerg.rosenkranz@gmail.com","sentAt":"2012-11-18T17:18:56Z","receivedAt":"2012-11-18T17:18:56Z","isPatch":false,"sender":{"key":"joerg.rosenkranz@gmail.com","avatar":null},"body":"2012/11/15 Javier Domingo \n>\n> Is there any way to avoid this? I mean, can something be done in git,\n> that it checks for (when pulling) the same objects in the other forks?\n\n\nI've been using git-new-workdir\n(https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir)\nfor a similar problem. Maybe that's what you're searching?\n\nJoerg.\n"}]}