Jason Pyeron <jpye...@pdinc.us>:
> If we take the below example:
>
> committer Name <user@domain> 1557948240 -0400
>
> and we follow the rule that:
>
> 1. any trailing zero after the decimal point MUST be omitted
> 2. if there are no digits after the decimal point, it MUST be omitted
>
> This would allow:
>
> committer Name <user@domain> 1557948240 -0400
> committer Name <user@domain> 1557948240.12 -0400
>
> but the following are never allowed:
>
> committer Name <user@domain> 1557948240. -0400
> committer Name <user@domain> 1557948240.000000 -0400
>
> By following these rules, all previous commits' hash are unchanged. Future
> commits made on the top of the second will look like old commit formats.
> Commits coming from "older" tools will produce valid and mergeable objects.
> The loss precision has frustrated us several times as well.
Yes, that's almost exactly what I came up with. I was concerned with upward
compatibility in fast-export streams, which reposurgeon ingests and emits.
But I don't quite understand your claim that there's no format
breakage here, unless you're implying to me that timestamps are already
stored in the git file system as variable-length strings. Do they
really never get translated into time_t? Good news if so.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
