Jeff King <p...@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.
And if we were to add "committer-timestamp" and friends to support
negative timestamps anyway (because older tools will not support
them), supporting sub-second part might be something we want to
think about at the same time.
We would however need to be extra careful. How should we express
half-second past Tue Nov 27 23:24:16 2012 (US/Pacific)? Would we
spell it 1354087456.5? 1354087456.500? Would we require decimal
representation of floating point numbers to be normalized in some
way (e.g. minimum number of digits without losing precision)? The
same timestamp needs to be expressed the same way, or we will end up
with different commit objects, which defeats the whole purpose of
introducing subsecond timestamps to support round-trip conversions.
If we were to use a separate "subsecond" fields, another thing we
need to be careful about is the order of these extra fields, exactly
for the same reason.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html