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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Jul 05 06:19:36 2006
This archive was generated by hypermail 2.1.8 : 2006-07-05 06:20:02 EST