On 5/15/2019 4:28 PM, Jason Pyeron wrote: > (please don’t cc me) Ok. I'll "To" you.
> 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 This kind of change would probably break old clients trying to read commits from new clients. Ævar's suggestion [1] of additional headers should not create incompatibilities. > 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. What problem are you trying to solve where commit date is important? The only use I have for them is "how long has it been since someone made this change?" A question like "when was this change introduced?" is much less important than "in which version was this first released?" This "in which version" is a graph reachability question, not a date question. I think any attempt to understand Git commits using commit date without using the underling graph topology (commit->parent relationships) is fundamentally broken and won't scale to even moderately-sized teams. I don't even use "git log" without a "--topo-order" or "--graph" option because using a date order puts unrelated changes next to each other. --topo-order guarantees that a path of commits with only one parent and only one child appears in consecutive order. Thanks, -Stolee P.S. All of my (overly strong) opinions on using commit date are made more valid when you realize anyone can set GIT_COMMITTER_DATE to get an arbitrary commit date. [1] https://public-inbox.org/git/871s0zwjv0....@evledraar.gmail.com/T/#t
