Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]

From: Nicolas Pitre <nico@cam.org>
Date: Dec 17, 2008, 16:15 UTC
Message-ID: <alpine.LFD.2.00.0812171104340.30035@xanadu.home>
In-Reply-To: <20081217154407.GZ32487@spearce.org>

On Wed, 17 Dec 2008, Shawn O. Pearce wrote:

Show 13 quoted lines

> Nicolas Pitre <nico@cam.org> wrote:
> > The fact is, fundamentally, we don't know how many bytes to push when 
> > generating a pack to answer the clone request.  Sometimes we _could_ but 
> > not always.  It is therefore better to be consistent and let people know 
> > that there is simply no ETA.
> 
> Hmm.
> 
> What if on an initial clone (no "have" lines received) we sum up
> the sizes of the *.pack and all of the loose objects and sent
> that as an initial size estimate.  Its going to be the upper bound
> of the final pack that we send.  At worst it over-estimates on the
> size and download finishes faster.

It is a kludge. It makes the system imprecise for little benefit. Once you start adding kludges like that into your system, people will always ask for more kludges, and in the end your system isn't as reliable. We all know about some other operating system which was designed like that. I personally don't want to go there.

Show 5 quoted lines

> Yea, a single stray binary of some *.mpg or *.iso accidentally
> added and then removed (and now unreachable) will vastly inflate
> the numbers.  In which case the repository owner will be encouraged
> to prune when people won't clone his estimated 8 GiB download,
> which is actually only 1 MiB.

And I consider any system doing such thing completely stupid. Either you consistently know the information or you don't. When you don't, it is best to not create expectations for the user. And so far I think that 99.9% of git users are just fine with the progress display we currently provide.

Nicolas