Re: [PATCH] Additional merge-base tests

[A Large Angry SCM <gitzilla@gmail.com>]

Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 4 Jul 2006, Junio C Hamano wrote:
> 
>> A Large Angry SCM <gitzilla@gmail.com> 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.