Re: git: uh-oh

Max Bowsher wrote:
> On 25/08/10 12:36, Heikki Linnakangas wrote:
>> On 25/08/10 14:03, Max Bowsher wrote:
>>> cvs2git will try to use the timestamps from the commits, but sometimes
>>> the ordering of how revisions and tags relate to each other will
>>> actually disagree with the timestamps. In such a case, cvs2git nudges
>>> commit timestamps forward in time, to force the defined temporal
>>> ordering into consistency with the topological ordering of events.
>> Hmm, why does it force that consistency? AFAIK git is happy with a
>> commit with an older timestamp following a commit with a newer timestamp.
> 
> Um. Good point. Why do enforce that?

Shallow answers:

* It was adopted from cvs2svn, where timestamp monotonicity is not quite
required but definitely advantageous.

* Non-monotonic timestamps give one a spooky feeling of time travel.


Deeper answers:

* Even though git is tolerant of timestamps that are out of order, that
doesn't mean that they are desirable.  The most common reason for
out-of-order CVS timestamps is that the CVS clients and/or server had
clocks that were incorrect.  (Several projects have reported that their
server had a dead CMOS battery, causing the clock to be reset to 1970
for a while.)  So often the enforced-monotonic timestamps produced by
cvs2svn are an improvement on the CVS timestamps.

* CVS (when functioning correctly) cannot generate events that are out
of chronological order.  Therefore, non-chronological events ipso facto
represent repository corruption and it would be silly to try to preserve
them.  (The exception is that cvs2svn might combine commits too
aggressively within its 5-minute timestamp window.)


So I think that it makes sense to keep at least part of the "ensure
monotonicity" behavior.

However, there is one big difference between Subversion and git:
Subversion requires a total ordering of commits, whereas git only
requires a topological ordering.  Currently, the "ensure monotonicity"
code is applied after the commits have been totally ordered.  Therefore,
any mistakes made in choosing a total order among those consistent with
the topological ordering constraints can lead to monotonicity fixups
that are not justified by the topology.  It might make sense, in the
case of DVCSs, to fix up timestamps at an earlier step in the conversion.

> Michael, do you think anything would break if we just removed the
> "ensure monotonicity" code?

No.  It might be interesting to turn it off and see where the
differences appear.

Michael