Re: [RFC PATCH v5 0/8] rebase-interactive

On 3/27/2018 1:07 AM, Junio C Hamano wrote: Jeff Hostetler writes: [...] So I would think it is most sensible to have double, uintmax_t and intmax_t variants. If you do not care about the extra value range that unsigned integral types afford, a single intmax_t

Re: [RFC PATCH v5 0/8] rebase-interactive

Jeff Hostetler writes: > I did the uint64_t for the unsigned ns times. > > I did the other one for the usual signed ints. > > I could convert them both to a single signed 64 bit typed function > if we only want to have one function. I still think having sized version is

Re: [RFC PATCH v5 0/8] rebase-interactive

Hi all, On Mon, 26 Mar 2018, Wink Saville wrote: > > I was just going by what the reported compiler error message was. > > It said that "unsigned long" didn't match the uint64_t variable. > > And that made me nervous. > > > > If all of the platforms we build on define uintmax_t >= 64 bits, > >

Re: [RFC PATCH v5 0/8] rebase-interactive

Wink Saville writes: > Should we add a "_Static_assert" that sizeof(uintmax_t) >= sizeof(uint64_t) ? If that expression compiles, then both types are understood by the platform. Because http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html tells us:

Re: [RFC PATCH v5 0/8] rebase-interactive

> I was just going by what the reported compiler error message was. > It said that "unsigned long" didn't match the uint64_t variable. > And that made me nervous. > > If all of the platforms we build on define uintmax_t >= 64 bits, > then it doesn't matter. > > If we do have a platform where

Re: [RFC PATCH v5 0/8] rebase-interactive

On 3/26/2018 2:00 PM, Junio C Hamano wrote: Jeff Hostetler writes: I am concerned that the above compiler error message says that uintmax_t is defined as an "unsigned long" (which is defined as *at least* 32 bits, but not necessarily 64. But a uint64_t is defined as

Re: [RFC PATCH v5 0/8] rebase-interactive

On 3/26/2018 1:57 PM, Junio C Hamano wrote: Jeff Hostetler writes: I defined that routine to take a uint64_t because I wanted to pass a nanosecond value received from getnanotime() and that's what it returns. Hmph, but the target format does not have different

Re: [RFC PATCH v5 0/8] rebase-interactive

Jeff Hostetler writes: > I am concerned that the above compiler error message says that uintmax_t > is defined as an "unsigned long" (which is defined as *at least* 32 bits, > but not necessarily 64. But a uint64_t is defined as a "unsigned long long" > and guaranteed as

Re: [RFC PATCH v5 0/8] rebase-interactive

Jeff Hostetler writes: > I defined that routine to take a uint64_t because I wanted to > pass a nanosecond value received from getnanotime() and that's > what it returns. Hmph, but the target format does not have different representation of inttypes in different sizes,

Re: [RFC PATCH v5 0/8] rebase-interactive

On 3/26/2018 11:56 AM, Junio C Hamano wrote: Wink Saville writes: json-writer.c:123:38: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] strbuf_addf(>json,

Re: [RFC PATCH v5 0/8] rebase-interactive

Wink Saville writes: > json-writer.c:123:38: error: format specifies type 'uintmax_t' (aka > 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned > long long') [-Werror,-Wformat] > > strbuf_addf(>json, ":%"PRIuMAX, value); >

Re: [RFC PATCH v5 0/8] rebase-interactive

>> I queued everything (with all patch 3-8/8 retitled to share a >> common prefix, so that "git shortlog" output would stay sane) >> and I think I resolved the conflicts with Dscho's recreate-merges >> topic correctly. Please double check what will appear on 'pu' later >> today. >> >> Thanks. >>

Re: [RFC PATCH v5 0/8] rebase-interactive

On Fri, Mar 23, 2018 at 3:39 PM, Junio C Hamano wrote: > Wink Saville writes: > >> On Fri, Mar 23, 2018 at 2:25 PM, Wink Saville wrote: >>> Reworked patch 1 so that all of the backend scriptlets >>> used by git-rebase use a normal function

Re: [RFC PATCH v5 0/8] rebase-interactive

Wink Saville writes: > On Fri, Mar 23, 2018 at 2:25 PM, Wink Saville wrote: >> Reworked patch 1 so that all of the backend scriptlets >> used by git-rebase use a normal function style invocation. >> >> Merged the previous patch 2 and 3 have been squashed

Re: [RFC PATCH v5 0/8] rebase-interactive

Wink Saville writes: > Wink Saville (8): > rebase-interactive: simplify pick_on_preserving_merges > rebase: update invocation of rebase dot-sourced scripts > Indent function git_rebase__interactive > Extract functions out of git_rebase__interactive > Add and use

Re: [RFC PATCH v5 0/8] rebase-interactive

On Fri, Mar 23, 2018 at 2:25 PM, Wink Saville wrote: > Reworked patch 1 so that all of the backend scriptlets > used by git-rebase use a normal function style invocation. > > Merged the previous patch 2 and 3 have been squashed which > provides reviewers a little easier time to

[RFC PATCH v5 0/8] rebase-interactive

Reworked patch 1 so that all of the backend scriptlets used by git-rebase use a normal function style invocation. Merged the previous patch 2 and 3 have been squashed which provides reviewers a little easier time to detect any changes during extraction of the functions. Wink Saville (8):