Re: [RFC/PATCH 0/2] Commits with ancient timestamps

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 3, 2012, 18:01 UTC
Message-ID: <7v1uqbssnf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87mx90yz5y.fsf@thomas.inf.ethz.ch>

Thomas Rast <trast@inf.ethz.ch> writes:

> Doing this just makes me wonder how important exactly the 1970-1975
> range is.  Is there a notable software history from that era that can be
> recovered?

That is not really a valid question. People who wrote private stuff in that era deserve to be users of Git, too.

> (Your [1/2] does not seem to parse negative offsets from the unix epoch,
> so anything before 1970 is still out.)

Yes, pre-epoch timestamps are also useful for projects like US Constitution.

  http://thread.gmane.org/gmane.comp.version-control.git/152433/focus=152725

For that, we would need to use and pass around time_t (or intmax_t if we follow the reason why originally Linus chose to avoid time_t) throughout the codebase. If you actually write commit objects that record pre-epoch timestamps, however, they will become unreadable by the current versions of Git (as they would not understand such a negative raw timestamp).

In any case, that is a goal for a much longer term.

But even after such a change happens, you still need a way for Git to replay a raw timestamp stored in commit objects without regressing the parse_date() interface too much. These two patches show one way to do so with minimum disruption.

As an added bonus, with the second patch, the way to spell a raw timestamp happens to become compatible with how GNU date accepts one, i.e.

        $ date -d @1000000000

even though we do not have to encourage the use of this notation by humans, tools and script writers may find it useful.