Re: Local clones aka forks disk size optimization

> On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>> On 15 November 2012 12:15, Javier Domingo <javierdo1@gmail.com> wrote:
>>> Hi Andrew,
>>>
>>> Doing this would require I got tracked which one comes from which. So
>>> it would imply some logic (and db) over it. With the hardlinking way,
>>> it wouldn't require anything. The idea is that you don't have to do
>>> anything else in the server.
>>>
>>> I understand that it would be imposible to do it for windows users
>>> (but using cygwin), but for *nix ones yes...
>>> Javier Domingo
>>
>> Paraphrasing from git-clone(1):
>>
>> When cloning a repository, if the source repository is specified with
>> /path/to/repo syntax, the default is to clone the repository by making
>> a copy of HEAD and everything under objects and refs directories. The
>> files under .git/objects/ directory are hardlinked to save space when
>> possible. To force copying instead of hardlinking (which may be
>> desirable if you are trying to make a back-up of your repository)
>> --no-hardlinks can be used.
>>
>> So hardlinks should be used where possible, and if they are not try
>> upgrading Git.
>>
>> I think that covers all the use cases you have?
> 
> I am not sure it does.  My understanding is this:
> 
> 'git clone -l' saves space on the initial clone, but subsequent pushes
> end up with the same objects duplicated across all the "forks"
> (assuming most of the forks keep up with some canonical repo).
> 
> The alternates mechanism can give you ongoing savings (as long as you
> push to the "main" repo first), but it is dangerous, in the words of
> the git-clone manpage.  You have to be confident no one will delete a
> ref from the "main" repo and then do a gc or let it auto-gc.
> 
> He's looking for something that addresses both these issues.
> 
> As an additional idea, I suspect this is what the namespaces feature
> was created for, but I am not sure, and have never played with it till
> now.
> 
> Maybe someone who knows namespaces very well will chip in...
>