From: A Large Angry SCM Date: Tue, 04 Jul 2006 20:18:57 GMT Subject: Re: [PATCH] Additional merge-base tests Message-ID: <44AACD31.70702@gmail.com> In-Reply-To: Johannes Schindelin wrote: > Hi, > > On Tue, 4 Jul 2006, Junio C Hamano wrote: > >> A Large Angry SCM 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.