Re: rs/strbuf-addftime-zZ, was Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 14, 2017, 18:23 UTC
Message-ID: <xmqqzida2ztd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.21.1.1706141245520.171564@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 21 quoted lines

> Hold on. Have you tried to build this branch?
>
> -- snip --
>     CC date.o
> date.c:63:36: error: unknown type name ‘timestamp_t’
>  static struct tm *time_to_tm_local(timestamp_t time)
>                                     ^
> date.c: In function ‘show_date’:
> date.c:211:8: error: implicit declaration of function ‘time_to_tm_local’
> [-Werror=implicit-function-declaration]
>    tm = time_to_tm_local(time);
>         ^
> date.c:211:6: error: assignment makes pointer from integer without a cast
> [-Werror=int-conversion]
>    tm = time_to_tm_local(time);
>       ^
> cc1: all warnings being treated as errors
> -- snap --
>
> I would expect this to be rebased *at least* to dddbad728c9 (timestamp_t:
> a new data type for timestamps, 2017-04-26).

Thanks for noticing.

My preference is to use ulong in the commit at the tip by Peff. We can do s/ulong/timestamp_t/ in a merge that merges the topic to newer integration branches that have the timestamp_t topic merged (e.g. 'master'), as that allows older integration branches (e.g. 'maint') to have the %z/%Z fix independently.

It would be another valid approach to fork it at b15667bb ("Merge branch 'js/larger-timestamps'", 2017-05-16) or a commit that appears later than that one on 'master', and tweak Peff's commit to use timestamp_t, if we declare that the %z/%Z fix will only be in 2.14 and later and will never go to 'maint'.