Re: [PATCH] Additional merge-base tests
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jul 4, 2006, 10:38 UTC
- Message-ID
- <7vsllhhcxr.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.63.0607041019580.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 6 quoted lines
> We could introduce a time.maximumSkew variable, and just walk only > that much further when traversing the commits. > > So, if you do not trust your clients to have a proper ntp setup, just say > "I trust my peers to be off at most 1 day". That would save lots vs > traverse-everything.
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
\ | /
0The 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
\ | /
0However, I am not sure how you are going to use that maximumSkew variable. The evil owner of the middle branch may have started running a "git am" to commit 4-patch series just when the machine's clock jumped back by 3 seconds, at the pace of 1 patch a second. Then he pushes '0' out on "master" branch, and the three commits on top of that on "next" branch.
Two days later, two friends build left and right strands of pearls based on the "master" branch of the evil owner of the middle branch. Maybe they do that one patch a day. On the fifth day, they both merge the "next" branch.
The point is that it does not require a very large clock skew to trigger this.