Sitaram Chamarty venit, vidit, dixit 15.11.2012 04:44: > 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... > I dunno about namespaces, but a safe route with alternates seems to be: Provide one "main" clone which is bare, pulls automatically, and is there to stay (no pruning), so that all others can use that as a reliable alternates source. Michael -- 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