Re: Millisecond precision in timestamps?

[Felipe Contreras <felipe.contreras@gmail.com>]

On Wed, Nov 28, 2012 at 9:19 AM, Thomas Berg <merlin66b@gmail.com> wrote:
> On Wed, Nov 28, 2012 at 8:29 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.

I'm not entirely sure. The API seems to return a float for the time,
but at least as far I can see, it never has any decimals anyway.

But it doesn't really matter, mercurial doesn't have a committer
information either. This is solved by tools like hg-git by storing the
information in an 'extra' field, which can store anything.

Unfortunately git doesn't have a similar field, so people have been
using the commit message to store extra information.

Either way, I don't see the point in changing git's commit format for
external tools. The git-notes functionality works just fine for that,
it just needs to be attached in the relevant places, like 'git
fast-export'.

BTW. Have you checked git's native support for hg?[1]

Cheers.

[1] http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/

-- 
Felipe Contreras