Is there way to set git commit --date to be older than 1970 ?

Is there way to set git commit --date to be older than 1970 ?

[Peter Vojtek]

Hello all,

I am playing with git in slightly unusual manner - e.g., to use git to
store history of europe:

$ touch Italy
$ git add Italy
$ git commit -m "add Italy" --date="01/01/1861T01:01:01" # Italy
gained sovereignity at year 1861
fatal: invalid date format: 01/01/1861T01:01:01

It seems the commit date can be between 1970 and 2100 (on my 32bit
linux), however man git (section DATE FORMATS) claims ISO 8601
standard is supported.  ISO 8601 allows even B.C. dates (via minus
sign).


I understand that this is rather an esoteric use case :)

Regards,

Peter

Re: Is there way to set git commit --date to be older than 1970 ?

[Fredrik Gustafsson]

On Wed, Oct 29, 2014 at 07:49:19PM +0100, Peter Vojtek wrote:
> I am playing with git in slightly unusual manner - e.g., to use git to
> store history of europe:

Actually you're the second person I hear that is trying to use git as a
timeline of some sort. The previous person had the exact same problem.
Unfortunately I couldn't find a mailthread about it in the archives.

I'm curious, why did you choose git for this? Maybe this is a use case
we should consider?

-- 
Med vänlig hälsning
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

Re: Is there way to set git commit --date to be older than 1970 ?

[Peter Vojtek]

thanks for quick response, Fredrik.

> I'm curious, why did you choose git for this? Maybe this is a use case
we should consider?

this is a part of "thinking out of the box" mental execise.

With the advent of many tools to visualize and analyze git
repositories, it makes some sense to use the underlying beauty and
power of git for unusual use cases. Similar evolution happened to
javascript (originally a simple language to apply form validations on
browser side).

Here are few other use cases which may be fun to realize with git:

- history of political parties in one country. when a party splits
into two, we create new branch, and when parties join, we merge
branches. branch name = party name. commiter name = party leader.

- how country populations evolve year by year. country is a file,
bytesize equals to its population.

- track evolution of some political document (e.g., u.s. constitution).



Peter


On Wed, Oct 29, 2014 at 8:19 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> On Wed, Oct 29, 2014 at 07:49:19PM +0100, Peter Vojtek wrote:
>> I am playing with git in slightly unusual manner - e.g., to use git to
>> store history of europe:
>
> Actually you're the second person I hear that is trying to use git as a
> timeline of some sort. The previous person had the exact same problem.
> Unfortunately I couldn't find a mailthread about it in the archives.
>
> I'm curious, why did you choose git for this? Maybe this is a use case
> we should consider?
>
> --
> Med vänlig hälsning
> Fredrik Gustafsson
>
> tel: 0733-608274
> e-post: iveqy@iveqy.com

Re: Is there way to set git commit --date to be older than 1970 ?

[Junio C Hamano]

Peter Vojtek <peter.vojtek@gmail.com> writes:

> It seems the commit date can be between 1970 and 2100 (on my 32bit
> linux),...

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 understand that this is rather an esoteric use case :)

Yeah, this is pretty much outside of what we intend to support.

Thanks.

Re: Is there way to set git commit --date to be older than 1970 ?

[Roberto Eduardo Decurnex Gorosito]

Peter,

You should be happy of getting the error message.

 Since Git 2 invalid years will default to the current year (keeping
the given day and month) without warnings.

--
Roberto Decurnex

On Wed, Oct 29, 2014 at 4:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Peter Vojtek <peter.vojtek@gmail.com> writes:
>
>> It seems the commit date can be between 1970 and 2100 (on my 32bit
>> linux),...
>
> 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 understand that this is rather an esoteric use case :)
>
> Yeah, this is pretty much outside of what we intend to support.
>
> Thanks.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is there way to set git commit --date to be older than 1970 ?

[Dan Johnson]

On Wed, Oct 29, 2014 at 3:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Peter Vojtek <peter.vojtek@gmail.com> writes:
>
>> It seems the commit date can be between 1970 and 2100 (on my 32bit
>> linux),...
>
> 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

-Dan Johnson

Re: Is there way to set git commit --date to be older than 1970 ?

[Jeff King]

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

Re: Is there way to set git commit --date to be older than 1970 ?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

There are only three places we store timestamps that matter in the
on-disk representations, so if we were to go 64-bit internally,
which I do not mind at all, we probably should do all three i.e.,
committer, tagger and author dates.

Re: Is there way to set git commit --date to be older than 1970 ?

[Junio C Hamano]

Peter Vojtek <peter.vojtek@gmail.com> writes:

> It seems the commit date can be between 1970 and 2100 (on my 32bit
> linux), however man git (section DATE FORMATS) claims ISO 8601
> standard is supported.

The date formats section of "git log" only talks about the output
format (I do not see in "man git" any section about date formats, by
the way), once Git understands and records the timestamp in its
internal representation (which is "seconds since the epoch"; as I
already said, theoretically it should be possible to record negative
number of seconds there, the current code does not allow it).

The documentation may need to be clarified, independent from what
the implementation does on the input side.  The current text from
"git log" reads like so:

       --date=(relative|local|default|iso|iso-strict|rfc|short|raw)
           Only takes effect for dates shown in human-readable
           format, such as when using --pretty.  log.date config
           variable sets a default value for the log command’s
           --date option.

The word "shown" is meant to stress that this description is about
output side, but apparently it was misread as if somehow a user can
affect the input by giving --date=iso or something, so perhaps you
would want to suggest a better phrasing?

Thanks.