Re: Back-dating commits--way back--for constitution.git

From: Joshua Juran <jjuran@gmail.com>
Date: Aug 3, 2010, 09:32 UTC
Message-ID: <FF986C58-37A5-41ED-B2AF-1EA4C045B9F7@gmail.com>
In-Reply-To: <4C57D997.5010003@drmicha.warpmail.net>

On Aug 3, 2010, at 1:55 AM, Michael J Gruber wrote:

Show 9 quoted lines

> 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!).
>

Show 9 quoted lines

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