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

Johannes Schindelin [off-list ref] 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'.