Hello
Earlier, I sent you an email on git@vger.kernel.org please confirm if you got
my message?
Angy Omari
Private Phone+447031903929
omaria...@yandex.com
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
val;
---
One thing I wonder is if this hashcpy() is doing anything useful,
though. Is ref->new_sha1 used after we are done in this codepath,
or is the reason nobody noticed it is because it does not matter
whatever garbage is in that field nobody looks at it?
My thoughts exactly. hence the &q
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
Greetings to you,
I want you to assist me in transferring the sum of US$9.5M left behind by my
dead client. I am willing to offer 50% to you as the sole beneficiary after the
funds has been transferred to you.
Get back to me if you are interested so that i can provide you with more details
Re
Greetings to you,
I am Jack Kofi, esq. I want to solicit your consideration to receive some funds
(US$9.5M) on my behalf.
Get back to me if you are interested so that i can provide you with more
details.
Yours Sincerely,
Jack Kofi
--
To unsubscribe from this list: send the line "unsubscribe gi
12 matches
Mail list logo
