Hi,
On 20/05/2019 15:41, Michal Suchánek wrote:
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)
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
