On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill <andrew.ardill@xxxxxxxxx> wrote: > On 15 November 2012 12:15, Javier Domingo <javierdo1@xxxxxxxxx> 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... -- 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