Re: [PATCH] Additional merge-base tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin wrote:
Hi,

On Tue, 4 Jul 2006, Junio C Hamano wrote:

A Large Angry SCM <gitzilla@xxxxxxxxx> writes:

This is a good demonstration that merge-base may not give you
minimal set for pathological cases.  If you want to be through
you could traverse everything to make sure we do not say 'S' is
relevant, but that is quite expensive, so I think there will
always be artifacts of horizon effect like this no matter how
you try to catch it (didn't I keep saying that already?).
The problem is in mark_reachable_commits(); it is either superfluous
or it needs to parse_commit() those commits that haven't been parsed
yet that it needs to traverse.
Yes, you could traverse everything.  But that is not practical.
We have known that the clean-up pass has this horizon effect,
and it is a compromise.

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 fuzz would only serve to mask, even more, that the heuristic is broken. But, it would also allow the (broken) heuristic to be used _and_ let the user decide how much effort may be used to find the correct bases.

If this happens, it should be (yet another) user configurable; either, per repository, command line, or both.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]