On Aug 3, 2010, at 1:55 AM, Michael J Gruber wrote:
Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value. You would have to use
system
that has 64-bit time_t, or patch git.
64-bit time_t would be enough for everyone (sic!).
time_t is signed on most systems. Using unsigned long buys us a few
years as long as we don't go through any system routine nor conversion
to time_t. So maybe we should:
- check to make sure we use time_t and system routines only when
getting
the current time
- use signed long long as our git_time_t (I think long is less system
dependent then long but I could be wrong)
Obviously you mean "I think long long is less system dependent than
long".
Does any system exist where long long is not 64 bits? In any case,
you can future-proof it by spelling it "int64_t". That symbol is not
guaranteed to exist (nor is <stdint.h>), but neither is the long long
type in the first place.
- make our own algorithms work for the extended format
This would enable systems with 32-bit time_t to deal with pre-1901
commit timestamps in Git.[1] Hopefully such systems will become
increasingly rare.
Josh
[1] Or post-2038 timestamps, but any use case for such is dubious.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html