On Thu, Mar 19, 2015 at 12:01:26PM -0700, Junio C Hamano wrote:
> > I'm working up a few patches in that area, which I'll send out in a few
> > minutes. Once that is done, then I think the explanation you give above
> > would be correct.
>
> If a follow-up is coming then I'd just drop this one.
Jeff King writes:
>> - The only caller of everything_local(), do_fetch_pack(), returns
>>this list of ref, whose element has bogus new_sha1 values, to its
>>caller. It does not look at the elements and acts on them.
>
> I'm not sure what the final sentence means. Should it be "It does n
On Thu, Mar 19, 2015 at 10:41:50AM -0700, Junio C Hamano wrote:
> Just to make sure we do not keep this hanging forever and eventually
> forget it, I'm planning to queue this.
Thanks for following up. A few minor nits (and maybe a more serious
problem) on the explanation in the commit message:
>
Jeff King writes:
> ...
> And there we stop. We don't pass the "refs" list out of that function
> (which, as an aside, is probably a leak). Instead, we depend on the list
> of heads we already knew in the "to_fetch" array. That comes from
> processing the earlier list of refs returned from get_re
On Sat, Mar 14, 2015 at 11:37:37PM -0700, Kyle J. McKay wrote:
> Peff, weren't you having some issue with want and have and hide refs?
Yes, but the problem was on the server side. I didn't look at this code
at all. :)
> Tell me please how the "local" variable above gets initialized?
So I think
On Mar 15, 2015, at 00:30, Junio C Hamano wrote:
Junio C Hamano writes:
"Kyle J. McKay" writes:
Hi guys,
So I was looking at fetch-pack.c (from master @ 52cae643, but I
think
it's the same everywhere):
...
- hashcpy(ref->new_sha1, local);
+ hashcpy(ref->n
Junio C Hamano writes:
> "Kyle J. McKay" writes:
>
>> Hi guys,
>>
>> So I was looking at fetch-pack.c (from master @ 52cae643, but I think
>> it's the same everywhere):
>>
> ...
>> -hashcpy(ref->new_sha1, local);
>> +hashcpy(ref->new_sha1, o->sha1);
>> if (
"Kyle J. McKay" writes:
> Hi guys,
>
> So I was looking at fetch-pack.c (from master @ 52cae643, but I think
> it's the same everywhere):
>
> # Lines 626-648
>
49bb805e (Do not ask for objects known to be complete., 2005-10-19)
seems to lose the assignment to local[].
> Something's very wrong
Hi guys,
So I was looking at fetch-pack.c (from master @ 52cae643, but I think
it's the same everywhere):
# Lines 626-648
for (retval = 1, ref = *refs; ref ; ref = ref->next) {
const unsigned char *remote = ref->old_sha1;
unsigned char local[20];
str
9 matches
Mail list logo
