Max Bowsher <maxb@f2s.com> writes:
> 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?
> Michael, do you think anything would break if we just removed the
> "ensure monotonicity" code?
Yes, the cases that I noticed all had to do with some curious condition,
like a time-extended CVS commit overlapping with another one on a
disjoint set of files. (The sets of files had to be disjoint or CVS
would have failed one commit at some point.) AFAICS there is no reason
the git conversion can't arbitrarily choose one order or the other, and
I would like it to choose an order based on real file commit timestamps
rather than made-up ones.
Some other cases that I noticed involved these manufactured commits that
we've been whining about --- the "real" commit that straightens things
out tends to be displaced by a minute or so, to no purpose whatsoever
since in most cases there are no nearby commits.
regards, tom lane