Re: Millisecond precision in timestamps?

From: Thomas Berg <merlin66b@gmail.com>
Date: Nov 28, 2012, 08:19 UTC
Message-ID: <CABYiQpmEpdf3L56NYSvPWovNOs_ifqj5QctuPSMoygHyMrz8+g@mail.gmail.com>
In-Reply-To: <7v7gp6i3rx.fsf@alter.siamese.dyndns.org>

On Wed, Nov 28, 2012 at 8:29 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> There is room for new headers, and older versions of git will ignore
>> them. You could add a new "committer-timestamp" field that elaborates on
>> the timestamp included on the committer line. Newer versions of git
>> would respect it, and older versions would fall back to using the
>> committer timestamp.
>>
>> But I really wonder if anybody actually cares about adding sub-second
>> timestamp support, or if it is merely "because SVN has it".
>
> Roundtrip conversions may benefit from sub-second timestamps, but
> personally I think negative timestamps are more interesting and of
> practical use.  Prehistoric projects need them even if they intend
> to switch to Git, never to go back to their original tarballs and
> collection of RCS ,v files.

If roundtripping to other version control systems is an argument, adding sub-second timestamps could potentially create as many problems as it solves. For example, I've been using the hg-git bridge, and it supports roundtripping between git and mercurial today (for most repos I've tried anyway). I may have missed something, but this could imply that mercurial doesn't care about sub-second timestamps either. If so, and if git suddenly were to record it, it would no longer be as straight forward to represent git history in hg.

In my opinion it would be a shame to sacrifice this compatibility just to reduce the distance to svn, which is much larger anyway.

- Thomas