From: Philip Oakley <philipoakley@iee.org>
Date: Fri, 24 Aug 2012 12:46:18 GMT
Subject: Re: [PATCH 00/17] Clean up how fetch_pack() handles the heads list
Message-ID: <DA390375EB8D4F21ADE618B88F1F0C4C@PhilipOakley>
In-Reply-To: <7vd32g3ol6.fsf@alter.siamese.dyndns.org>

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Friday, August 24, 2012 5:23 AM
> Jeff King <peff@peff.net> writes:
>
>>> It may be (?) that it is a good time to think about a 'datedepth'
>>> capability to bypass the current counted-depth shallow fetch that 
>>> can
>>> cause so much trouble. With a date limited depth the relevant tags
>>> could also be fetched.
>>
>> I don't have anything against such an idea, but I think it is 
>> orthogonal
>> to the issue being discussed here.
>
> Correct.
>
> The biggest problem with the "shallow" hack is that the deepening
> fetch counts from the tip of the refs at the time of deepening when
> deepening the history (i.e. "clone --depth", followed by number of
> "fetch", followed by "fetch --depth").  If you start from a shallow
> clone of depth 1, repeated fetch to keep up while the history grew
> by 100, you would still have a connected history down to the initial
> cauterization point, and "fetch --depth=200" would give you a
> history that is deeper than your original clone by 100 commits.  But
> if you start from the same shallow clone of depth 1, did not do
> anything while the history grew by 100, and then decide to fetch
> again with "fetch --depth=20", it does not grow.  It just makes
> 20-commit deep history from the updated tip, and leave the commit
> from your original clone dangling.
>
> The problem with "depth" does not have anything to do with how it is
> specified at the UI level.

That is, correct me if I'm wrong, the server currently lacks a 
capability to provide anything other than the counted depth shallow 
response (if available). Hence my comment about needing an additional 
server side capability, though that would need a well thought out set of 
use cases to make it useful.

>                                       The end-user input is used to 
> find out
> at what set of commits the history is cauterized, and once they are
> computed, the "shallow" logic solely works on "is the history before
> these cauterization points, or after, in topological terms." (and it
> has to be that way to make sure we get reproducible results).  Even
> if a new way to specify these cauterization points in terms of date
> is introduced, it does not change anything and does not solve the
> fundamental problem the code has when deepening.

fundamental problem = no server capability other than counted depth.
>