Hi Hannes,
On Mon, 5 Nov 2018, Johannes Sixt wrote:
> Am 05.11.18 um 00:26 schrieb Junio C Hamano:
> > OK, thanks. It seems that the relative silence after this message is
> > a sign that the resulting patch after squashing is what everybody is
> > happey with?
>
> I'm not 100% happy. I'll
Am 05.11.18 um 08:01 schrieb Johannes Sixt:
Am 05.11.18 um 00:26 schrieb Junio C Hamano:
OK, thanks. It seems that the relative silence after this message
is a sign that the resulting patch after squashing is what everybody
is happey with?
I'm not 100% happy.
I see the patch is already in
Am 05.11.18 um 00:26 schrieb Junio C Hamano:
OK, thanks. It seems that the relative silence after this message
is a sign that the resulting patch after squashing is what everybody
is happey with?
I'm not 100% happy. I'll resend a squashed patch, but it has to wait as
I have to catch a train
Eric Sunshine writes:
> On Sun, Nov 4, 2018 at 6:26 PM Junio C Hamano wrote:
>> OK, thanks. It seems that the relative silence after this message
>> is a sign that the resulting patch after squashing is what everybody
>> is happey with?
>>
>> -- >8 --
>> From: Steve Hoelzer
>>
>>
On Sun, Nov 4, 2018 at 6:26 PM Junio C Hamano wrote:
> OK, thanks. It seems that the relative silence after this message
> is a sign that the resulting patch after squashing is what everybody
> is happey with?
>
> -- >8 --
> From: Steve Hoelzer
>
> Signed-off-by: Johannes Sixt
> Acked-by:
On November 4, 2018 6:26 PM, Junio C Hamano, wrote:
> Johannes Sixt writes:
>
> > Am 03.11.18 um 09:14 schrieb Carlo Arenas:
> >> On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
> >>>
> >>> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout -
> >>> + elapsed);
> >>
> >>
Johannes Sixt writes:
> Am 03.11.18 um 09:14 schrieb Carlo Arenas:
>> On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
>>>
>>> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout -
>>> elapsed);
>>
>> nitpick: cast to DWORD instead of int
>
> No; timeout is of type int; after
Am 03.11.18 um 09:14 schrieb Carlo Arenas:
On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
+ timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout - elapsed);
nitpick: cast to DWORD instead of int
No; timeout is of type int; after an explicit type cast we don't want to
have
On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
>
> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout - elapsed);
nitpick: cast to DWORD instead of int
Carlo
Junio C Hamano writes:
> Johannes Sixt writes:
>
>>> Yep, correct on all counts. I'm in favor of changing the commit message to
>>> only say that this patch removes Warning C28159.
>>
>> How about this fixup instead?
>
> Isn't that already in 'next'? I didn't check, though.
Well, it turnsout
Johannes Sixt writes:
>> Yep, correct on all counts. I'm in favor of changing the commit message to
>> only say that this patch removes Warning C28159.
>
> How about this fixup instead?
Isn't that already in 'next'? I didn't check, though.
On Fri, Nov 2, 2018 at 11:43 AM Johannes Sixt wrote:
>
> Am 02.11.18 um 15:47 schrieb Steve Hoelzer:
> > On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote:
> >>
> >> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
> >>> @@ -614,7 +618,7 @@ restart:
> >>>
> >>> if (!rc &&
Am 02.11.18 um 15:47 schrieb Steve Hoelzer:
> On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote:
>>
>> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
>>> @@ -614,7 +618,7 @@ restart:
>>>
>>> if (!rc && orig_timeout && timeout != INFTIM)
>>>{
>>> - elapsed =
On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote:
>
> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
> > From: Steve Hoelzer
> >
> > From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
> > 'GetTickCount64' instead of 'GetTickCount'.
> >
> > Reason:
Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
From: Steve Hoelzer
From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
'GetTickCount64' instead of 'GetTickCount'.
Reason: GetTickCount() overflows roughly every 49 days. Code that does
not take that into account
From: Steve Hoelzer
>From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
'GetTickCount64' instead of 'GetTickCount'.
Reason: GetTickCount() overflows roughly every 49 days. Code that does
not take that into account can loop indefinitely. GetTickCount64()
operates on 64 bit
16 matches
Mail list logo
