Re: [PATCH] Additional merge-base tests
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jul 4, 2006, 11:16 UTC
- Message-ID
- <e8dim7$8cm$1@sea.gmane.org>
- In-Reply-To
- <7vsllhhcxr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 28 quoted lines
> The problem ALASCM's example demonstrates does rely on clock > skews. The timestamps used in the example looked like this: > > > 1 1 > / \/ \ > 4 -1 4 > | | | > 3 -2 3 > | | | > 2 -3 2 > \ | / > 0 > > The crucial clock skew the case relies on is that the tip of the > middle branch (-1) is older than the common commit (0). But the > topmost commits with timestamp 1 could be with timestamp 5 to > correct the clock skew and still make the example "fail". > > 5 5 > / \/ \ > 4 -1 4 > | | | > 3 -2 3 > | | | > 2 -3 2 > \ | / > 0
So would putting timestamp for merge be MAX(now, parents timestamps) solve the problem?
-- Jakub Narebski Warsaw, Poland ShadeHawk on #git