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

From: Nicolas Pitre <nico@cam.org>
Date: Dec 17, 2008, 16:46 UTC
Message-ID: <alpine.LFD.2.00.0812171136250.30035@xanadu.home>
In-Reply-To: <20081217162127.GG32487@spearce.org>

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

Show 17 quoted lines

> Nicolas Pitre <nico@cam.org> wrote:
> > 
> > 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.
> 
> Certainly true here; I never care how big the source I'm cloning is.
> But then again I have pretty good network connectivity at work
> and at least cable modem service at home...  most things clone down
> pretty fast.
> 
> Its a quick hack to give a size upper bound.  I don't think its
> that ugly.  Our network protocol is uglier with all of its hidden
> fields jammed behind that NUL in the first advertisement line.
> But I digress.

The ugliness in the protocol is encapsulated away from user view, and we could even seemlessly introduce a new protocol at any time with no issues if we wanted to.

This "quick hack" is imprecise, unreliable, and directly affect user perception. This is way more dammageable as once users are used to it, good or bad, it won't be possible to get rid of it.

> The better feature is probably resumable clone anyway.  At least
> then people can abort a "long running" clone and have a good chance
> they can pick it up again in the near future.

Absolutely.

> Its also not easy to
> implement, which is why we've only been talking about it for years
> and never actually seen a patch proposing to do it.

A partial clone could possibly be turned into a shalow clone if at least the top commit is complete ...

Nicolas