Re: Finer timestamps and serialization in git

From: Philip Oakley <philipoakley@iee.org>
Date: May 20, 2019, 22:18 UTC
Message-ID: <2f0ab8c9-adf4-416d-519a-a313de89d5e1@iee.org>
In-Reply-To: <20190520164134.6b35b9f9@kitsune.suse.cz>

Hi,

On 20/05/2019 15:41, Michal Suchánek wrote:

Show 6 quoted lines

>>   But you were talking as though all those commits
>> have to be modified*after they're in the DAG*, and that's not the case.
>> If any timestamp has to be modified, it only has to happen*once*, at the
>> time its commit enters the repo.
> And that's where you get it wrong. Git is*distributed*. There is more
> than one repository. Each repository has its own DAG

So far so good. In fact it the change to 'distributed' that has ruined Eric's Acton stamps that assume that the 'time' came from a single central server.

>   that is completely
> unrelated to the other repositories and their DAGs.

This bit will confuse. It is only the new commits in the different repositories that are 'unrelated'. Their common history commits are identical sha1 values, and the DAG links back to their common root commit(s)

Show 6 quoted lines

> So when you take
> your history and push it to another repository and the timestamps
> change as the result what ends up in the other repository is not the
> history you pushed. So the repositories diverge and you no longer know
> what is what.
>

If the sender tweaks their timestamps at commit time, then no one 'knows'. It's just a minor bit of clock drift/slop. But once they have a cascaded history which has been published (and used) you are locked into that.

As noted previously. The significant change is the loss of the central server and the referential nature of it's clock time stamp.

If the action stamp is just a useful temporary intermediary in a transfer then cheats are possible (e.g. some randomising hash of a definative partr of the commit).

But if the action stamps are meant to be permanent and re-generatable for a round trip between a central server change set based server to Git, and then back again, repeatably, without divergence, loss, or change, then it is not going to happen reliably. To do so requires the creation of fixed total order (by design - single clock) from commits that are only partially ordered (by design! - DAG rather than multiple unsynchronized user clocks).

For backward compatibility Git only has (and only needs 1 second resolution).

The multi-decade/century VCS idea of a master artifact and then near copies (since koalin and linen drawings, blue prints, ..) with central _control_ is being replaced by zero cost perfect replication, authentication by hash, with its distribution of control (of artifact entry into the VCS) to _users_, from managers. Managers simply select and decide on the artifact quality and authorize the use of a hash.

Most folks haven't really looked below the surface of what it is that makes GIT and DVCS so successful, and it's not just the Linus effect. The previous certainties (e.g. the idea of a total order to allow logging by change-set) have gone.

--

Philip