On May 23, 2019 17:19, Eric S. Raymond wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx>: > > Honestly, I do think you have missed some fundamental issues. > > https://public-inbox.org/git/ab3222ab-9121-9534-1472- > fac790bf08a4@gmai > > l.com/ > > discusses this further. > > Have re-read. That was a different pair of proposals. > > I have abandoned the idea of forcing timestamp uniqueness entirely - that > was a hack to define a canonical commit order, and my new RFC describes a > better way to get this. > > I still think finer-grained timestamps would be a good idea, but that is much > less important than the different set of properties we can guarantee via the > new RFC. I don't think finer-grained timestamps will help long-term. The faster systems get, the more resolution we need. At this point, I can easily get two commits within the same microsecond. The weird part is that if the commits are done from two different CPUs on my platform, it is theoretically possible (although highly unlikely) that the second commit could be one microsecond earlier than the first commit, on the same file system, if a inter-CPU clock-sync had not been done for the past few seconds. On a broader scale, that is somewhat obvious and assumes global time synchronisation is maintained. It also makes me wonder what happens when git runs on a quantum computer and a commit goes to the wrong universe (joke). Just my $0.014 Randall
