Re: Finer timestamps and serialization in git

From: Derrick Stolee <stolee@gmail.com>
Date: May 15, 2019, 20:16 UTC
Message-ID: <ae62476c-1642-0b9c-86a5-c2c8cddf9dfb@gmail.com>
In-Reply-To: <20190515191605.21D394703049@snark.thyrsus.com>

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.

Show 5 quoted lines

> 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.

Show 8 quoted lines

> 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