Re: Local clones aka forks disk size optimization

From: Enrico Weigelt <enrico.weigelt@vnc.biz>
Date: Nov 18, 2012, 17:02 UTC
Message-ID: <27f681a7-f87d-47b4-a512-93511b44b286@zcs>
In-Reply-To: <CAMK1S_hCk3QdDn8XnXVisL1i2V0iPCZBYN989JmZ3JYr7ckRrA@mail.gmail.com>

Hi,

> That's not the only problem.  I believe you only get the savings when
> the main repo gets the commits first.  Which is probably ok most of
> the time but it's worth mentioning.

Well, the saving will just be deferred to the point where the commit finally went to the main repo and downstreams are gc'ed.

Show 7 quoted lines

> > hmm, distributed GC is a tricky problem.
> 
> Except for one little issue (see other thread, subject line "cloning
> a
> namespace downloads all the objects"), namespaces appear to do
> everything we want in terms of the typical use cases for alternates,
> and/or 'git clone -l', at least on the server side.

hmm, not sure about the actual internals, but that namespace filtering should work in a way that local clone should never see (or consider) remote refs that are outside of the requested namespace. Perhaps that should be handled entirely on server side, so all called commands treat these refs as nonexisting.

By the way: what happens if one tries to clone from an broken repo (which has several refs pointing to nonexisting objects ?

cu

-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weigelt@vnc.biz; www.vnc.de