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

[Junio C Hamano <gitster@pobox.com>]

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

> 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'.