On 08/23/2012 10:31 PM, Jeff King wrote:
> On Thu, Aug 23, 2012 at 03:56:48PM -0400, Jeff King wrote:
>
>> This code blames back to:
>>
>> commit 4bcb310c2539b66d535e87508d1b7a90fe29c083
>> Author: Alexandre Julliard
>> Date: Fri Nov 24 16:00:13 2006 +0100
>>
>> fetch-pack: Do not fetch
On 08/23/2012 10:31 PM, Jeff King wrote:
> I think part of the confusion of this code is that inside the loop over
> the refs it is sometimes checking aspects of the ref, and sometimes
> checking invariants of the loop (like args.fetch_all). Splitting it into
> separate loops makes it easier to see
From: "Junio C Hamano"
Sent: Friday, August 24, 2012 5:23 AM
Jeff King 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 als
Jeff King 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
From: "Jeff King"
Sent: Thursday, August 23, 2012 8:56 PM
On Thu, Aug 23, 2012 at 08:13:29PM +0100, Philip Oakley wrote:
>>I'm still suspicious about the logic related to args.fetch_all and
>>args.depth, but I don't think I've made anything worse.
>
>I think the point of that is that when doin
On Thu, Aug 23, 2012 at 03:56:48PM -0400, Jeff King wrote:
> This code blames back to:
>
> commit 4bcb310c2539b66d535e87508d1b7a90fe29c083
> Author: Alexandre Julliard
> Date: Fri Nov 24 16:00:13 2006 +0100
>
> fetch-pack: Do not fetch tags for shallow clones.
>
> A better fix may
On Thu, Aug 23, 2012 at 08:13:29PM +0100, Philip Oakley wrote:
> >>I'm still suspicious about the logic related to args.fetch_all and
> >>args.depth, but I don't think I've made anything worse.
> >
> >I think the point of that is that when doing "git fetch-pack --all
> >--depth=1", the meaning of
From: "Jeff King"
Sent: Thursday, August 23, 2012 10:26 AM
On Thu, Aug 23, 2012 at 10:10:25AM +0200, mhag...@alum.mit.edu wrote:
There were various confusing things (and a couple of bugs) in the way
that fetch_pack() handled the list (nr_heads, heads) of references to
be sought from the remote
On Thu, Aug 23, 2012 at 10:10:25AM +0200, mhag...@alum.mit.edu wrote:
> There were various confusing things (and a couple of bugs) in the way
> that fetch_pack() handled the list (nr_heads, heads) of references to
> be sought from the remote:
Aside from the minor comments I made to individual pat
From: Michael Haggerty
There were various confusing things (and a couple of bugs) in the way
that fetch_pack() handled the list (nr_heads, heads) of references to
be sought from the remote:
* Different names were used for the list in different functions for no
special reason.
* fetch_pack() m
10 matches
Mail list logo
