From: Jeff King <peff@peff.net>
To: Dan Johnson <computerdruid@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Peter Vojtek <peter.vojtek@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Is there way to set git commit --date to be older than 1970 ?
Date: Thu, 30 Oct 2014 17:48:52 -0400 [thread overview]
Message-ID: <20141030214852.GB21017@peff.net> (raw)
In-Reply-To: <CAPBPrnuxAPmKe_aRb9USh=cOu4jMZaYzOorXC_RJa8b8ROq+iA@mail.gmail.com>
On Thu, Oct 30, 2014 at 05:08:56PM -0400, Dan Johnson wrote:
> > The underlying data representation records time as number of seconds
> > since epoch (1970-01-01). Theoretically the codepaths that read
> > data could consider negative timestamps to represent times before
> > the epoch, but in the context of source code control, negative
> > values are more likely to be an indication of a bug or a user
> > mistake, and I do not think any existing code in Git is prepared to
> > pass such a timestamp as a sane value---instead they diagnose a
> > failure and die.
>
> I remember a pretty old thread found some success storing timestamps this way:
> http://comments.gmane.org/gmane.comp.version-control.git/152433
A few things have changed since then. Most notably, git is more careful
about overflow of "unsigned long" when reading in timestamp values. Of
course, we can't do much in the overflow case except assign a sentinel
value. But it at least means that overflowing values all end up as "Jan
1 1970" and not whatever random 32-bit wraparound you happen to get.
But what _hasn't_ changed is that we still use "unsigned long"
internally. The fact that the 1787 date in that thread worked at all is
somewhat accidental and due to implicit casts between "unsigned long"
and "time_t" working. As noted here (and downthread):
http://permalink.gmane.org/gmane.comp.version-control.git/152508
I think it would be a nice project to convert git to consistently use
signed 64-bit times internally, and then everything would Just Work
going back to the beginning of history. But the demand for such a
feature has been low enough that nobody has really dug in and tried the
conversion.
We do also gain some small amount of efficiency by storing commit
timestamps as 32-bit values. However, those should always be "current"
times anyway. I think we are really talking about author timestamps
here (and of course the underlying time-manipulation functions).
-Peff
next prev parent reply other threads:[~2014-10-30 21:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 18:49 Is there way to set git commit --date to be older than 1970 ? Peter Vojtek
2014-10-29 19:19 ` Fredrik Gustafsson
2014-10-29 19:50 ` Peter Vojtek
2014-10-29 19:31 ` Junio C Hamano
2014-10-29 20:03 ` Roberto Eduardo Decurnex Gorosito
2014-10-30 21:08 ` Dan Johnson
2014-10-30 21:48 ` Jeff King [this message]
2014-10-30 22:11 ` Junio C Hamano
2014-10-30 17:24 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141030214852.GB21017@peff.net \
--to=peff@peff.net \
--cc=computerdruid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peter.vojtek@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.