On 5/15/2019 3:16 PM, Eric S. Raymond wrote: > The deeper problem is that I want something from Git that I cannot > have with 1-second granularity. That is: a unique timestamp on each > commit in a repository. This is impossible in a distributed version control system like Git (where the commits are immutable). No matter your precision, there is a chance that two machiens commit at the exact same moment on two different machines and then those commits are merged into the same branch. Even when you specify a committer, there are many environments where a set of parallel machines are creating commits with the same identity. > Why do I want this? There are number of reasons, all related to a > mathematical concept called "total ordering". At present, commits in > a Git repository only have partial ordering. This is true of any directed acyclic graph. If you want a total ordering that is completely unambiguous, then you should think about maintaining a linear commit history by requiring rebasing instead of merging. > One consequence is that > action stamps - the committer/date pairs I use as VCS-independent commit > identifications in reposurgeon - are not unique. When a patch sequence > is applied, it can easily happen fast enough to give several successive > commits the same committer-ID and timestamp. Sorting by committer/date pairs sounds like an unhelpful idea, as that does not take any graph topology into account. It happens that commits can actually have an _earlier_ commit date than its parent. > More deeply, the lack of total ordering means that repository graphs > don't have a single canonical serialized form. This sounds abstract > but it means there are surgical operations I can't regression-test > properly. My colleague Edward Cree has found cases where git fast-export > can issue a stream dump for which git fast-import won't necessarily > re-color certain interior nodes the same way when it's read back in > and I'm pretty sure the absence of total ordering on the branch tips > is at the bottom of that. If you use `git rev-list --topo-order` with a fixed set of refs to start, then the total ordering given is well-defined (and it is a linear extension of the partial order given by the commit graph). However, this ordering is not stable: adding another merge commit may swap the order between two commits lower in the order. > I'm willing to write patches if this direction is accepted. I've figured > out how to make fast-import streams upward-compatible with finer-grained > timestamps. Changing the granularity of timestamps requires changing the commit format, which is probably a non-starter. More universally-useful suggestions have been blocked due to keeping the file format consistent. Thanks, -Stolee
